Multi-process communication regarding gaming information

ABSTRACT

Various embodiments that may generally relate to mobile gaming, location determination, mobile devices, authentication, and so on are described. Various methods are described. Various apparatuses are described. Further embodiments are described.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/900,494 filed Jun. 12, 2020, which is a continuation of U.S. patentapplication Ser. No. 14/640,439 filed Mar. 6, 2015, which is acontinuation of U.S. patent application Ser. No. 13/080,098 filed Apr.5, 2011, which is a continuation-in-part of U.S. patent application Ser.No. 13/070,893 filed on Mar. 24, 2011, which is hereby incorporatedherein by reference. This application claims priority to U.S.Provisional Application No. 61/373,435 filed on Aug. 13, 2010; U.S.Provisional Application No. 61/405,309 filed on Oct. 21, 2010; U.S.Provisional Application No. 61/405,439 filed on Oct. 21, 2010; U.S.Provisional Application No. 61/413,098 filed on Nov. 12, 2010; and U.S.Provisional Application No. 61/413,089 filed on Nov. 12, 2010, which areall hereby incorporated herein by reference.

FIELD

Some embodiments may generally relate to gaming and/or mobile devices.

BACKGROUND

Mobile devices, such as cellular telephones, PDAs, notebook computers,and/or various other devices may be used by individuals.

Gaming, such as casino gaming, sports wagering, video gaming, and/orvarious other forms of gaming may be performed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a hand-reading system of someembodiments.

FIG. 2 shows apparatus for playing a game in some embodiments.

FIG. 3 shows an example process that may be used in some embodiments forvalidation and/or use of a mobile device.

FIG. 4 an example set of application that may be executed by a mobiledevice to facilitate access to a mobile gaming service.

FIG. 5 shows an example of a series of geofences shown on a map ofNevada. The circles/discs in the map represent sample geofences.

FIG. 6 shows some example processes that may be performed in someembodiments with respect to a geofence.

FIG. 7 some example processes that may be performed in some embodimentswith respect to a geofence.

FIG. 8 shows an example architecture that may be used in someembodiments for location determination.

DETAILED DESCRIPTION

The following sections I-X provide a guide to interpreting the presentapplication.

It will be readily apparent to one of ordinary skill in the art that thevarious processes described herein may be implemented by, e.g.,appropriately programmed general purpose computers, special purposecomputers and computing devices. Typically a processor (e.g., one ormore microprocessors, one or more microcontrollers, one or more digitalsignal processors) will receive instructions (e.g., from a memory orlike device), and execute those instructions, thereby performing one ormore processes defined by those instructions. Instructions may beembodied in, e.g., one or more computer programs, one or more scripts.

A “processor” means one or more microprocessors, central processingunits (CPUs), computing devices, microcontrollers, digital signalprocessors, or like devices or any combination thereof, regardless ofthe architecture (e.g., chip-level multiprocessing/multi-core, RISC,CISC, Microprocessor without Interlocked Pipeline Stages, pipeliningconfiguration, simultaneous multithreading).

Thus a description of a process is likewise a description of anapparatus for performing the process. The apparatus that performs theprocess can include, e.g., a processor and those input devices andoutput devices that are appropriate to perform the process.

Further, programs that implement such methods (as well as other types ofdata) may be stored and transmitted using a variety of media (e.g.,computer readable media) in a number of manners. In some embodiments,hard-wired circuitry or custom hardware may be used in place of, or incombination with, some or all of the software instructions that canimplement the processes of various embodiments. Thus, variouscombinations of hardware and software may be used instead of softwareonly.

The term “computer-readable medium” refers to any medium, a plurality ofthe same, or a combination of different media, that participate inproviding data (e.g., instructions, data structures) which may be readby a computer, a processor or a like device. Such a medium may take manyforms, including but not limited to, non-volatile media, volatile media,and transmission media. Non-volatile media include, for example, opticalor magnetic disks and other persistent memory. Volatile media includedynamic random access memory (DRAM), which typically constitutes themain memory. Transmission media include coaxial cables, copper wire andfiber optics, including the wires that comprise a system bus coupled tothe processor. Transmission media may include or convey acoustic waves,light waves and electromagnetic emissions, such as those generatedduring radio frequency (RF) and infrared (IR) data communications.Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, any other magneticmedium, a CD-ROM, DVD, any other optical medium, punch cards, papertape, any other physical medium with patterns of holes, a RAM, a PROM,an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a carrierwave as described hereinafter, or any other medium from which a computercan read.

Various forms of computer readable media may be involved in carryingdata (e.g. sequences of instructions) to a processor. For example, datamay be (i) delivered from RAM to a processor; (ii) carried over awireless transmission medium; (iii) formatted and/or transmittedaccording to numerous formats, standards or protocols, such as Ethernet(or IEEE 802.3), SAP, ATP, Bluetooth□, and TCP/IP, TDMA, CDMA, and 3G;and/or (iv) encrypted to ensure privacy or prevent fraud in any of avariety of ways well known in the art.

Thus a description of a process is likewise a description of acomputer-readable medium storing a program for performing the process.The computer-readable medium can store (in any appropriate format) thoseprogram elements which are appropriate to perform the method.

Just as the description of various steps in a process does not indicatethat all the described steps are required, embodiments of an apparatusinclude a computer/computing device operable to perform some (but notnecessarily all) of the described process.

Likewise, just as the description of various steps in a process does notindicate that all the described steps are required, embodiments of acomputer-readable medium storing a program or data structure include acomputer-readable medium storing a program that, when executed, cancause a processor to perform some (but not necessarily all) of thedescribed process.

Where databases are described, it will be understood by one of ordinaryskill in the art that (i) alternative database structures to thosedescribed may be readily employed, and (ii) other memory structuresbesides databases may be readily employed. Any illustrations ordescriptions of any sample databases presented herein are illustrativearrangements for stored representations of information. Any number ofother arrangements may be employed besides those suggested by, e.g.,tables illustrated in drawings or elsewhere. Similarly, any illustratedentries of the databases represent exemplary information only; one ofordinary skill in the art will understand that the number and content ofthe entries can be different from those described herein. Further,despite any depiction of the databases as tables, other formats(including relational databases, object-based models and/or distributeddatabases) could be used to store and manipulate the data typesdescribed herein. Likewise, object methods or behaviors of a databasecan be used to implement various processes, such as the describedherein. In addition, the databases may, in a known manner, be storedlocally or remotely from a device which accesses data in such adatabase.

Various embodiments can be configured to work in a network environmentincluding a computer that is in communication (e.g., via acommunications network) with one or more devices. The computer maycommunicate with the devices directly or indirectly, via any wired orwireless medium (e.g. the Internet, LAN, WAN or Ethernet, Token Ring, atelephone line, a cable line, a radio channel, an optical communicationsline, commercial on-line service providers, bulletin board systems, asatellite communications link, a combination of any of the above). Eachof the devices may themselves comprise computers or other computingdevices, such as those based on the Intel® Pentium® or Centrino™processor, that are adapted to communicate with the computer. Any numberand type of devices may be in communication with the computer.

In an embodiment, a server computer or centralized authority may not benecessary or desirable. For example, the present invention may, in anembodiment, be practiced on one or more devices without a centralauthority. In such an embodiment, any functions described herein asperformed by the server computer or data described as stored on theserver computer may instead be performed by or stored on one or moresuch devices.

Where a process is described, in an embodiment the process may operatewithout any user intervention. In another embodiment, the processincludes some human intervention (e.g., a step is performed by or withthe assistance of a human).

Tracking the Action at a Table

U.S. Pat. No. 6,579,181 generally describes, “a system for automaticallymonitoring playing and wagering of a game. In one illustratedembodiment, the system includes a card deck reader that automaticallyreads a respective symbol from each card in a deck of cards before afirst one of the cards is removed from the deck. The symbol identifies avalue of the card in terms of rank and suit, and can take the form of amachine-readable symbol, such as a bar code, area or matrix code orstacked code. In another aspect, the system does not decode the readsymbol until the respective card is dealt, to ensure security.

“In another aspect, the system can include a chip tray reader thatautomatically images the contents of a chip tray. The systemperiodically determines the number and value of chips in the chip trayfrom the image and compares the change in contents of the chip tray tothe outcome of game play to verify that the proper amounts have beenpaid out and collected.

“In a further aspect, the system can include a table monitor thatautomatically images the activity or events occurring at a gaming table.The system periodically compares images of the gaming table to identifywagering, as well as the appearance, removal and position of cardsand/or other objects on the gaming table. The table monitoring systemcan be unobtrusively located in the chip tray.”

U.S. Pat. No. 6,579,181 generally describes “a drop box thatautomatically verifies an amount and authenticity of a deposit andreconciles the deposit with a change in the contents of the chip tray.The drop box can image different portions of the deposited item,selecting appropriate lighting and resolutions to examine securityfeatures in the deposited item.

“In another aspect, the system can employ some, or all of the componentsto monitor the gaming habits of players and the performance ofemployees. The system can detect suspect playing and wagering patternsthat may be prohibited. The system can also identify the win/losspercentage of the players and the dealer, as well as a number of otherstatistically relevant measures. Such measures can provide a casino orother gaming establishment with enhanced automated security, andautomated real-time accounting. The measures can additionally provide abasis for automatically allocating complimentary benefits to theplayers.”

Various embodiments include an apparatus, method and system whichutilizes a card dispensing shoe with scanner and its associated softwarewhich enable the card dealer when dealing the game from a carddispensing shoe with scanner preferably placed on a game table where thetwenty-one game to be evaluated by the software is being played, to useone or more keyboard(s) and/or LCD displays coupled to the shoe toidentify for the computer program the number of the active players'seats, or active players, including the dealer's position relativethereto and their active play at the game table during each game rounddealt from the shoe. These keyboards and LCD displays are also used toenter other data relevant to each seat's, or player's, betting and/ordecision strategies for each hand played. The data is analyzed by acomputer software program designed to evaluate the strategy decisionsand betting skills of casino twenty-one, or blackjack players playingthe game of blackjack during real time. The evaluation software iscoupled to a central processing unit (CPU) or host computer that is alsocoupled to the shoe's keyboard(s) and LCD displays. The dealer using oneor more keyboard(s) attached to or carried by the shoe, or a keyboard(s)located near the dealer is able to see and record the exact amount betby each player for each hand played for the game to be evaluated. Theoptical scanner coupled to the CPU reads the value of each card dealt toeach player's hand(s) and the dealer's hand as each card is dealt to aspecific hand, seat or position and converts the game card value of eachcard dealt from the shoe to the players and the dealer of the game to acard count system value for one or more card count systems programmedinto the evaluation software. The CPU also records each playersdecision(s) to hit a hand, and the dealer's decision to hit or takeanother card when required by the rules of the game, as the hit card isremoved from the shoe. The dealer uses one or more of the keyboards andLCD displays carried by the shoe to record each player's decision(s) toInsure, Surrender, Stand, Double Down, or Split a hand. When the dealerhas an Ace or a Ten as an up-card, he/she may use one or more of thekeyboards to prompt the computer system's software, since the dealer'ssecond card, or hole-card, which is dealt face down, has been scannedand the game card value thereof has been imported into the computersystems software, to instantly inform the dealer, by means of one ormore of the shoe's LCDs, if his/her game cards, or hand total,constitutes a two-card “21” or “Blackjack”.

In various embodiments, a card playing system for playing a card gamewhich includes a card delivery shoe apparatus for use in dealing playingcards to at least one player for the playing of the card game comprises,in combination, housing means having a chute for supporting at least onedeck of playing cards for permitting movement of the playing cards oneat a time through the chute, the housing means having an outlet openingthat permits the playing cards of the deck to be moved one-by-one out ofthe housing means during the play of a card game, card scanning meanslocated within the housing means for scanning indicia located on each ofthe playing cards as each of the playing cards are moved out from thechute of the housing means, means for receiving the output of the cardscanning means for identifying each of the playing cards received byeach player from the shoe, for evaluating information relative to eachplayers received playing cards and their values with information as toplaying tactics used by each player relative to the values of thereceived playing cards, and for combining all of this information foridentifying each player's playing strategy, and a playing table coupledto the card delivery shoe apparatus and having at least one keypad meanslocated thereon for permitting at least one player to select variouscard playing options to wager upon.

In various embodiments, a card playing system for playing a card gamewhich includes a card delivery shoe apparatus for use in dealing playingcards to at least one player for the playing of the card game comprises,in combination, housing means having a chute for supporting at least onedeck of playing cards for permitting movement of the playing cards oneat a time through the chute, the housing means having an outlet openingthat permits the playing cards of the deck to be moved one-by-one out ofthe housing means during the play of a card game, card scanning meanslocated within the housing means for scanning indicia located on each ofthe playing cards as each of the playing cards are moved out from thechute of the housing means, means for receiving the output of the cardscanning means for identifying such of the playing cards received byeach player from the shoe apparatus, for evaluating information relativeto each player's received playing cards and their values withinformation as to betting tactics used by each player relative toplaying cards previously dealt out from the shoe apparatus providingcard count information, and for combining all of this information foridentifying each player's card count strategy, and a playing tablecoupled to the card delivery shoe apparatus and having at least onekeypad means located thereon for permitting the at least one player toselect at least one of various card playing options to wager upon.

In various embodiments, a card playing system for playing a card gamewhich includes a card delivery shoe apparatus for use in dealing playingcards to at least one player for the playing of a card game comprises,in combination, housing means having a chute for supporting at least onedeck of playing cards for permitting movement of the playing cards oneat a time through the chute, the housing means having an outlet openingthat permits the playing cards of the deck to be moved one-by-one out ofthe housing means during the play of a card game, card scanning meanslocated within the housing means for scanning indicia located on each ofthe playing cards as each of the playing cards are moved out from thechute of the housing means, means for receiving the output of the cardscanning means for identifying each of the playing cards received byeach player from the shoe apparatus, for evaluating information relativeto each player's received playing cards and their values withinformation as to playing tactics used by each player relative to thevalues of the received playing cards, for combining use of all of thisinformation for identifying each player's playing strategy, and for alsoidentifying each player's card count strategy based on each player'sbetting tactics used by each player relative to playing cards previouslydealt out from the shoe apparatus providing card count information, anda playing table coupled to the card delivery shoe apparatus and havingat least one keypad means located thereon for permitting the at leastone player to select at least one of various card playing options towager upon.

In various embodiments, a secure game table system, adapted for multiplesites under a central control, allows for the monitoring of hands in aprogressive live card game. A live card game has at least one deck, witheach deck having a predetermined number of cards. Each game table in thesystem has a plurality of player positions with or without players ateach position and a dealer at a dealer position.

In one embodiment, for providing additional security, a common identitycode is located on each of the cards in each deck. Each deck has adifferent common identity code. A shuffler is used to shuffle the deckstogether and the shuffler has a circuit for counting of the cards from aprevious hand that are inserted into the shuffler for reshuffling. Theshuffler circuit counts each card inserted and reads the common identitycode located on each card. The shuffler circuit issues a signalcorresponding to the count and the common identity code read. The gamecontrol (e.g., the computer) located at each table receives this signalfrom the shuffler circuit and verifies that no cards have been withdrawnfrom the hand by a player (or the dealer) or that no new cards have beensubstituted. If the count is not proper or if a game card lacks anidentity code or an identity code is mismatched, an alarm signal isgenerated indicating that a new deck of cards needs to be used and thatthe possibility of a breach in the security of the game has occurred.

In yet another embodiment of security, a unique code, such as a barcode, is placed on each card and as each card is dealt by the dealerfrom a shoe, a detector reads the code and issues a signal to the gamecontrol containing at least the value and the suit of each card dealt inthe hand. The detector may also read a common identity deck code andissue that as a signal to the game control. The shoe may have an opticalscanner for generating an image of each card as it is dealt from theshoe by the dealer in a hand. The game control stores this informationin a memory so that a history of each card dealt from the shoe in a handis recorded.

In yet another embodiment of security, an integrated shuffler/shoeobtains an optical image of each card dealt from the shoe for a hand andfor each card inserted into the shuffler after a hand. These images aredelivered to the game control where the images are counted and compared.When an irregular count or comparison occurs, an alarm is raised. Theshuffler and shoe are integrated to provide security between the twounits.

In another embodiment of security for a live card game, a game betsensor is located near each of the plurality of player positions forsensing the presence of a game bet. The game bet sensor issues a signalcounting the tokens placed. It is entirely possible that game betsensors at some player positions do not have bets, and therefore, thegame control that is receptive of these signals identifies which playerpositions have players placing game bets. This information is stored inmemory and becomes part of the history of the game.

In another embodiment of security, a progressive bet sensor is locatedat each of the plurality of player positions and senses the presence ofa progressive bet. The progressive bet sensor issues a signal that isreceived by the game control, which records in memory the progressivebets being placed at the respective player position sensed. If aprogressive bet is sensed and a game bet is not, the game control issuesan alarm signal indicating improper betting. At this point, the gamecontrol knows the identity of each player location having placed a gamebet and, of those player positions having game bets placed, which playerpositions also have a progressive bet. This is stored in memory as partof the history of the hand.

In yet another embodiment of security, a card sensor is located neareach player position and the dealer position. The card sensor issues asignal for each card received at the card sensor. The game controlreceives this issued signal and correlates those player positions havingplaced a game bet with the received cards. In the event a playerposition without a game bet receives a card or a player position with agame bet receives a card out of sequence, the game control issues analarm. This information is added to the history of the game in memory,and the history contains the value and suit of each card delivered toeach player position having a game bet.

A progressive jackpot display may be located at each game table and maydisplay one or more jackpot awards for one or more winning combinationsof cards. In one embodiment of the present invention, the game controlat each table has stored in memory the winning combinations necessary towin the progressive jackpots. Since the game control accurately storesthe suit and value of each card received at a particular playerposition, the game control can automatically detect a winningcombination and issue an award signal for that player position. Thedealer can then verify that that player at that position indeed has thecorrect combination of cards. The game control continuously updates thecentral control interconnected to all other game tables so that thecentral control can then inform all game tables of this win including,if desirable, the name of the winner and the amount won.

The central control communicates continuously with each game control andits associated progressive jackpot display may receive over acommunication link all or part of the information stored in each gamecontrol.

Various embodiments include a card shoe with a device for automaticrecognition and tracking of the value of each gaming card drawn out ofthe card shoe in a covered way (face down).

Various embodiments include a gaming table with a device for automaticrecognition of played or not played boxes (hands), whereby it has torealize multiple bets on each hand and the use of insurance lines.Furthermore, the gaming table may include a device to recognizeautomatically the number of cards placed in front of each player and thedealer.

Various embodiments include the recognition, tracking, and storage ofgaming chips.

In various embodiment, an electronic data processing (EDP) program mayprocess the value of all bets on each box and associated insurance line,control the sequence of delivery of the cards, control the distributionof the gaming cards to each player and the dealer, may calculate andcompare the total score of each hand and the dealer's, and may evaluatethe players' wins.

Gaming data may then be processed by means of the EDP program and shownsimultaneously to the actual game at a special monitor or display. Samedata may be recalled later on to monitor the total results wheneverrequested.

Various embodiments include a gaming table and a gaming table clotharranged on the gaming table, the gaming table cloth provided withbetting boxes and areas designated for placement of the gaming chips andother areas designated for placement of the playing cards, a card shoefor storage of one or more decks of playing cards, this card shoeincluding means for drawing individual ones of the playing cards facedown so that a card value imprint on the drawn card is not visible to aplayer of the game of chance, a card recognition means for recognizingthis card value imprint on the drawn card from the card shoe, this cardrecognition means being located in the card shoe, an occupation detectorunit including means for registering a count of gaming chips placed onthe designated areas and another count of playing cards placed on theother designated areas on the table cloth, this occupation detector unitbeing located under the table cloth and consisting of multiple singledetectors allocated to each betting box, each area for chips and eachother area for playing cards respectively, a gaming bet detector forautomatic recognition or manual input of gaming bets, and a computerincluding means for evaluating the play of the game of chance accordingto the rules of the game of chance, means for storing results of theplay of the game of chance and means for displaying a course of the playof the game of chance and the results from electronic signals input fromthe gaming bet detector, the occupation detector unit and the cardrecognition means.

According to various embodiments, the card recognition means comprisesan optical window arranged along a movement path of the card imageimprint on the playing card drawn from the card shoe; a pulsed lightsource for illuminating a portion of the drawn playing card locatedopposite the optical window; a CCD image converter for the portion ofthe drawn playing card located opposite the optical window; an opticaldevice for deflecting and transmitting a reflected image of the cardvalue imprint from the drawn playing card to the CCD image converterfrom that portion of the drawn playing card when the drawn card isexactly in a correct drawn position opposite the optical window; andsensor means for detecting movement of the drawn card and for providinga correct timing for operation of the pulsed light source fortransmission of the reflected image to the CCD image converter. Theoptical device for deflecting and transmitting the reflected image cancomprise a mirror arranged to deflect the reflected image to the CCDimage converter. Alternatively, the optical device for deflecting andtransmitting the reflected image comprises a reflecting optical prismhaving two plane surfaces arranged at right angles to each other, one ofwhich covers the optical window and another of which faces the CCD imageconverter and comprises a mirror, and the pulsed light source isarranged behind the latter plane surface so as to illuminate the drawncard when the drawn card is positioned over the optical window.Advantageously the sensor means for detecting movement of the drawn cardand for providing a correct timing comprises a single sensor, preferablyeither a pressure sensor or a photoelectric threshold device, forsensing a front edge of the drawn card to determine whether or not thedrawn card is being drawn and to activate the CCD image converter andthe pulsed light source when a back edge of the drawn card passes thesensor means. Alternatively, the sensor means can include twoelectro-optical sensors, one of which is located beyond a movement pathof the card image imprint on the drawn playing card and another of whichis located in a movement path of the card image imprint on a drawnplaying card. The latter electro-optical sensor can include means foractivating the pulsed light source by sensing a color trigger when thecard value imprint passes over the optical window. In preferredembodiments of the card shoe the pulsed light source comprises a Xenonlamp.

In various embodiments of the gaming apparatus the single detectors ofthe occupation detector unit each comprise a light sensitive sensor fordetection of chips or playing cards arranged on the tablecloth over therespective single detector. Each single detector can be an infraredsensitive photodiode, preferably a silicon photodiode. Advantageouslythe single detectors can be arranged in the occupation detector unit sothat the chips or playing cards placed over them on the tablecloth arearrange over at least two single detectors.

The gaming apparatus may include automatic means for discriminatingcolored markings or regions on the chips and for producing a bet outputsignal in accordance with the colored markings or regions and the numberof chips having identical colored markings or regions.

The gaming bet detector may include automatic means for discriminatingbetween chips of different value in the game of chance and means forproducing a bet output signal in accordance with the different values ofthe chips when the chips are bet by a player. In various embodiments thegaming bet detector includes a radio frequency transmitting andreceiving station and the chips are each provided with a transponderresponding to the transmitting and receiving station so that thetransponder transmits the values of the bet chips back to thetransmitting and receiving station.

The connection between the individual units of the gaming apparatus andthe computer can be either a wireless connection or a cable connection.

XIV. FOLLOWING THE BETS

Various embodiments include a smart card delivery shoe that reads thesuit and rank of each card before it is delivered to the variouspositions where cards are to be dealt in the play of the casino tablecard game. The cards are then dealt according to the rules of the gameto the required card positions. Different games have diverse carddistribution positions, different card numbers, and different deliverysequences that the hand identifying system of some embodiments of theinvention may encompass. For example, in the most complex of carddistribution games of blackjack, cards are usually dealt one at a timein sequence around a table, one card at a time to each player positionand then to the dealer position. The one card at a time deliverysequence is again repeated so that each player position and the dealerposition have an initial hand of exactly two cards. Complexity in handdevelopment is introduced because players have essentially unlimitedcontrol over additional cards until point value in a hand exceeds acount of twenty-one. Players may stand with a count of 2 (two aces) ortake a hit with a count of 21 if they are so inclined, so the knowledgeof the count of a hand is no assurance of what a player will do. Thedealer, on the other hand, is required to follow strict house rules onthe play of the game according to the value of the dealer's hand. Smallvariances such as allowing or disallowing a hit on a “soft” seventeencount (e.g., an Ace and a 6) may exist, but the rules are otherwise veryprecise so that the house or dealer cannot exercise any strategy.

Other cards games may provide equal numbers of cards in batches.Variants of stud poker played against a dealer, for example, wouldusually provide hands of five cards, five at a time to each playerposition and if competing against a dealer, to the dealer position. Thiscard hand distribution is quite simple to track as each sequence of fivecards removed from the dealer shoe is a hand.

Other games may require cards to be dealt to players and other cardsdealt to a flop or common card area. The system may also be programmableto cover this alternative if it is so desired.

Baccarat is closer to blackjack in card sequence of dealing but has morerigid rules as to when hits may be taken by the player and the dealer,and each position may take a maximum of one card as a hit. The handidentification system of some embodiments of the invention may be ableto address the needs of identifying hands in each of these types ofgames and especially may be able to identify hands in a complexsituation, the play of blackjack.

In various embodiments, where cameras are used to read cards, the lightsensitive system may be any image capture system, digital or analog,that is capable of identifying the suit and rank of a card.

In various embodiments, a first step in the operation is to provide aset of cards to the smart delivery shoe, the cards being those cardsthat are going to be used in the play of a casino table card game. Theset of cards (usually one or more decks) is provided in an alreadyrandomized set, being taken out of a shuffler or having been shuffled byhand. A smart delivery shoe is described in U.S. patent application Ser.No. 10/622,321, titled SMART DELIVERY SHOE, which application isincorporated herein in its entirety by reference. Some delivery systemsor shoes with reading capability include but are not limited to thosedisclosed in U.S. Pat. Nos. 4,750,743; 5,779,546; 5,605,334; 6,361,044;6,217,447; 5,941,769; 6,229,536; 6,460,848; 5,722,893; 6,039,650; and6,126,166. In various embodiments, the cards are read in the smart carddelivery shoe, such as one card at a time in sequence. Reading cards byedge markings and special codes (as in U.S. Pat. No. 6,460,848) mayrequire special encoding and marking of the cards. The entire sequenceof cards in the set of cards may thus be determined and stored inmemory. Memory may be at least in part in the smart delivery shoe, butcommunication with a central processor is possible. The sequence wouldthen also or solely be stored in the central computer.

In various embodiments, the cards are then dealt out of the smartdelivery shoe, the delivery shoe registering how many cards are removedone-at-a-time. This may be accomplished by the above identified U.S.patent application Ser. No. 10/622,321 where cards are fed to the dealerremoval area one at a time, so only one card can be removed by thedealer. As each card is removed, a signal is created indicating that aspecific card (of rank and suit) has been dealt. The computer and systemknow only that a first card has been dealt, and it is presumed to go tothe first player. The remaining cards are dealt out to players anddealer. In the play of certain games (e.g., stud variants) wherespecific numbers of cards are known to be dealt to each position, theshoe may be programmed with the number of players at any time, so handscan be correlated even before they have been dealt. If the shoe isplaying a stud variant where each player and the dealer gets three cards(Three Card Poker™ game), the system may know in advance of the dealwhat each player and the dealer will have as a hand. It is also possiblethat there be a signal available when the dealer has received either hisfirst card (e.g., when cards are dealt in sequence, one-at-a-time) orhas received his entire hand. The signal may be used to automaticallydetermine the number of player positions active on the table at anygiven time. For example, if in a hand of blackjack the dealer receivesthe sixth card, the system may immediately know that there are fiveplayers at the table. The signal can be given manually (pressing abutton at the dealer position or on the smart card delivery shoe) or canbe provided automatically (a card presence sensor at the dealer'sposition, where a card can be placed over the sensor to provide asignal). Where an automatic signal is provided by a sensor, somephysical protection of the sensor may be provided, such as a shield thatwould prevent accidental contact with the sensor or blockage of thesensor. An L-shaped cover may be used so a card could be slid under thearm of the L parallel to the table surface and cover the sensor underthat branch of the L. The signal can also be given after all cards forthe hand have been delivered, again indicating the number of players,For example, when the dealer's two cards are slid under the L-shapedcover to block or contact the sensor, the system may know the totalnumber of cards dealt on the hand (e.g., 10 cards), know that the dealerhas 2 cards, determine that players therefore have 8 cards, and knowthat each player has 2 cards each, thereby absolutely determining thatthere are four active player positions at the table (10−2=8 and then8/2=4 players). This automatic determination may serve as an alternativeto having dealers input the number of players each hand at a table orhaving to manually change the indicated number of players at a tableeach time the number changes.

Once all active positions have been dealt to, the system may now knowwhat cards are initially present in each player's hand, the dealer'shand, and any flop or common hand. The system operation may now besimple when no more cards are provided to play the casino table game.All hands may then be known, and all outcomes may be predicted. Thecomplication of additional cards will be addressed with respect to thegame of blackjack.

After dealing the initial set of two cards per hand, the system may notimmediately know where each remaining card will be dealt. The system mayknow what cards are dealt, however. It is with this knowledge and asubsequent identification of discarded hands that the hands and cardsfrom the smart delivery shoe can be reconciled or verified. Each hand isalready identified by the presence of two specifically known cards.Hands are then played according to the rules of the game, and hands arediscarded when play of a hand is exhausted. A hand is exhausted when 1)there is a blackjack, the hand is paid, and the cards are cleared; 2) ahand breaks with a count over twenty-one and the cards are cleared;and/or a round of the game is played to a conclusion, the dealer's handcompleted, all wagers are settled, and the cards are cleared. As istypically done in a casino to enable reconciling of hands manually,cards are picked up in a precise order from the table. The cards areusually cleared from the dealer's right to the dealer's left, and thecards at each position comprise the cards in the order that they weredelivered, first card on the bottom, second card over the first card,third card over the second card, etc. maintaining the order or a closeapproximation of the order (e.g., the first two cards may be reversed)is important as the first two cards form an anchor, focus, basis, fence,end point or set edge for each hand. For example, if the third playerposition was known to have received the 10 of hearts (10H) and the 9 ofspades (9S) for the first two card, and the fourth player was known toreceive the 8 of diamonds (8D) and the 3 of clubs (3C) for the first twocards, the edges or anchors of the two hands are 9S/10H and 8D/3C. Whenthe hands are swept at the conclusion of the game, the cards are sent toa smart discard rack (e.g., see U.S. patent application Ser. No.10/622,388, which application is incorporated herein by reference in itsentirety) and the hand with the 9S/10H was not already exhausted (e.g.,broken or busted) and the swept cards consist of 9S, 10H, 8S, 8D and 3C(as read by the smart discard rack), the software of the processor mayautomatically know that the final hands in the third and fourthpositions were a count of 19 (9S and 10H) for the third hand and 19 (8Dand 3C originally plus the 8S hit) for the fourth hand. The analysis bythe software specifically identifies the fourth hand as a count of 19with the specific cards read by the smart discard shoe. The informationfrom reading that now exhausted hand is compared with the originalinformation collected from the smart delivery shoe. The smart deliveryshoe information when combined with the smart discard rack informationshall confirm the hands in each position, even though cards were notuniformly distributed (e.g., player one takes two hits for a total offour cards, player two takes three hits for a total of five cards,player three takes no hit for a total of two cards, player four takesone hit for a total of three cards, and the dealer takes two hits for atotal of four cards).

The dealer's cards may be equally susceptible to analysis in a number ofdifferent formats. After the last card has been dealt to the lastplayer, a signal may be easily and imperceptibly generated that thedealer's hand will now become active with possible hits. For example,with the sensor described above for sensing the presence of the firstdealer card or the completion of the dealer's hand, the cards would beremoved from beneath the L-shaped protective bridge. This type ofmovement is ordinarily done in blackjack where the dealer has at most asingle card exposed, and one card buried face down. In this case, theremoval of the cards from over the sensor underneath the L-cover todisplay the hole card is a natural movement and then exposes the sensor.This can provide a signal to the central processor that the dealer'shand will be receiving all additional cards in that round of the game.The system at this point knows the two initial cards in the dealer'shand, knows the values of the next sequence of cards, and knows therules by which a dealer may play. The system knows what cards the dealerwill receive and what the final total of the dealer's hand will bebecause the dealer has no freedom of decision or movement in the play ofthe dealer's hand. When the dealer's hand is placed into the smartdiscard rack, the discard rack already knows the specifics of thedealer's hand even without having to use the first two cards as ananchor or basis for the dealer's hand. The cards may be treated in thismanner in some embodiments.

When the hands are swept from the table, dealer's hand then players'hands from right to left (from the dealer's position or vice-versa ifthat is the manner of house play), the smart discard rack reads theshoes, identifies the anchors for each hand, knows that no hands sweptat the conclusion can exceed a count of twenty-one, and the computeridentifies the individual hands and reconciles them with the originaldata from the smart delivery shoe. The system thereby can identify eachhand played and provide system assurance that the hand was played fairlyand accurately.

If a lack of reconciling by the system occurs, a number of events canoccur. A signal can be given directly to the dealer position, to the pitarea, or to a security zone and the cards examined to determine thenature and cause of the error and inspect individual cards if necessary.When the hand and card data is being used for various statisticalpurposes, such as evaluating dealer efficiency, dealer win/loss events,player efficiency, player win/loss events, statistical habits ofplayers, unusual play tactics or meaningful play tactics (e.g.,indicative of card counting), and the like, the system may file theparticular hand in a ‘dump’ file so that hand is not used in thestatistical analysis, this is to assure that maximum benefits of theanalysis are not tilted by erroneous or anomalous data.

Various embodiments may include date stamping of each card dealt (actualtime and date defining sequence, with concept of specific identificationof sequence identifier possibly being unique). The date stamping mayalso be replaced by specific sequence stamping or marking, such as aspecific hand number, at a specific table, at a specific casino, with aspecific number of players, etc. The records could indicate variationsof indicators in the stored memory of the central computer of Lucky 777Casino, Aug. 19, 1995, 8:12:17 a.m., Table 3, position 3, hand 7S/4D/9S,or simply identify something similar by alphanumeric code asL7C-819-95-3-3-073-7S/4D/9S (073 being the 73^(rd) hand dealt). Thisdate stamping of hands or even cards in memory can be used as ananalytical search tool for security and to enhance hand identification.

FIG. 1 shows a block diagram of the minimum components for thehand-reading system on a table 4 of some embodiments, a smartcard-reading delivery shoe 8 with output 14 and a smart card-readingdiscard rack 12 with output 18. Player positions 6 are shown, as is adealer's hand position sensor 10 without output port 16.

The use of the discard rack acting to reconcile hands returned to thediscard rack out-of-order (e.g., blackjack or bust) automatically may beadvantageous, in some embodiments. The software as described above canbe programmed to recognize hands removed out-of-dealing order on thebasis of knowledge of the anchor cards (the first two cards) known tohave been dealt to a specific hand. For example, the software willidentify that when a blackjack was dealt to position three, that handwill be removed, the feed of the third hand into the smart card discardtray confirms this, and position three will essentially be ignored infuture hand resolution. More importantly, when the anchor cards were,for example, 9S/5C in the second player position and an exhausted handof 8D/9S/5C is placed into the smart discard rack, that hand will beidentified as the hand from the second player position. If two identicalhands happen to be dealt in the same round of play, the software willmerely be alerted (it knows all of the hands) to specifically check thefinal order of cards placed into the smart discard rack to morecarefully position the location of that exhausted hand. This is merelyrecognition software implementation once the concept is understood.

That the step of removal of cards from the dealer's sensor or otherinitiated signal identifies that all further cards are going to thedealer may be useful in defining the edges of play between rounds and inidentifying the dealer's hand and the end of a round of play. When thedealer's cards are deposited and read in the smart discard rack, thecentral computer knows that another round of play is to occur, and amark or note may be established that the following sequence will be anew round and the analytical cycle may begin all over again.

The discard rack indicates that a complete hand has been delivered byabsence of additional cards in the Discard Rack in-feed tray. When cardsare swept from an early exhausted hand (blackjack or a break), they areswept one at a time and inserted into the smart discard rack one at atime. When the smart discard rack in-feed tray is empty, the systemunderstands that a complete hand has been identified, and the system canreconcile that specific hand with the information from the smartdelivery shoe. The system can be hooked-up to feed strategy analysissoftware programs such as the SMI licensed proprietary Bloodhound™analysis program.

Various embodiments include a casino or cardroom game modified toinclude a progressive jackpot component. During the play of a Twenty-Onegame, for example, in addition to this normal wager, a player will havethe option of making an additional wager that becomes part of, and makesthe player eligible to win, the progressive jackpot. If the player'sTwenty-One hand comprises a particular, predetermined arrangement ofcards, the player will win all, or part of, the amount showing on theprogressive jackpot. This progressive jackpot feature is also adaptableto any other casino or cardroom game such as Draw Poker, Stud Poker,Lo-Ball Poker or Caribbean Stud™ Poker. Various embodiments include agaming table, such as those used for Twenty-One or poker, modified withthe addition of a coin acceptor that is electronically connected to aprogressive jackpot meter. When player drops a coin into the coinacceptor, a light is activated at the player's location indicating thathe is participating in the progressive jackpot component of the gameduring that hand. At the same time, a signal from the coin acceptor issent to the progressive meter to increment the amount shown on theprogressive meter. At the conclusion of the play of each hand, the coinacceptor is reset for the next hand. When a player wins all or part ofthe progressive jackpot, the amount showing on the progressive jackpotmeter is reduced by the amount won by the player. Any number of gamingtables can be connected to a single progressive jackpot meter.

XV. CARD SHUFFLERS

Various embodiments include an automatic card shuffler, including a cardmixer for receiving cards to be shuffled in first and second trays.Sensors detect the presence of cards in these trays to automaticallyinitiate a shuffling operation, in which the cards are conveyed from thetrays to a card mixer, which randomly interleaves the cards delivered tothe mixing mechanism and deposits the interleaved cards in a verticallyaligned card compartment.

A carriage supporting an ejector is reciprocated back and forth in avertical direction by a reversible linear drive while the cards arebeing mixed, to constantly move the card ejector along the cardreceiving compartment. The reversible linear drive is preferablyactivated upon activation of the mixing means and operatessimultaneously with, but independently of, the mixing means. When theshuffling operation is terminated, the linear drive is deactivatedthereby randomly positioning the card ejector at a vertical locationalong the card receiving compartment.

A sensor arranged within the card receiving compartment determines ifthe stack of cards has reached at least a predetermined vertical height.After the card ejector has stopped and, if the sensor in the compartmentdetermines that the stack of cards has reached at least the aforesaidpredetermined height, a mechanism including a motor drive, is activatedto move the wedge-shaped card ejector into the card receivingcompartment for ejecting a group of the cards in the stack, the groupselected being determined by the vertical position attained by thewedge-shaped card ejector.

In various embodiments, the card ejector pushes the group of cardsengaged by the ejector outwardly through the forward open end of thecompartment, said group of cards being displaced from the remainingcards of the stack, but not being completely or fully ejected from thestack.

The card ejector, upon reaching the end of its ejection stroke, detectedby a microswitch, is withdrawn from the card compartment and returned toits initial position in readiness for a subsequent shuffling and cardselecting operation.

In various embodiments, a technique for randomly selecting the group ofcards to be ejected from the card compartment utilizes solid stateelectronic circuit means, which may comprise either a group of discretesolid state circuits or a microprocessor, either of which techniquespreferably employ a high frequency generator for stepping a N-stagecounter during the shuffling operation. When the shuffling operation iscompleted, the stepping of the counter is terminated. The output of thecounter is converted to a DC signal, which is compared against anotherDC signal representative of the vertical location of the card ejectoralong the card compartment.

In various embodiments, a random selection is made by incrementing theN-stage counter with a high frequency generator. The high frequencygenerator is disconnected from the N-stage counter upon termination ofthe shuffling operation. The N-stage counter is then incremented by avery low frequency generator until it reaches its capacity count andresets. The reciprocating movement of the card ejector is terminatedafter completion of a time interval of random length and extending fromthe time the high frequency generator is disconnected from the N-stagecounter to the time that the counter is advanced to its capacity countand reset by the low frequency generator, triggering the energization ofthe reciprocating drive, at which time the card ejector carriage coaststo a stop.

In various embodiments, the card ejector partially ejects a group ofcards from the stack in the compartment. The partially displaced groupof cards is then manually removed from the compartment. In anotherpreferred embodiment, the ejector fully ejects the group of cards fromthe compartment, the ejected cards being dropped into a chute, whichdelivers the cards directly to a dealing shoe. The pressure plate of thedealing shoe is initially withdrawn to a position enabling the cardspassing through the delivery shoe to enter directly into the dealingshoe and is thereafter returned to its original position at which iturges the cards towards the output end of the dealing shoe.

Various embodiments include a method and apparatus for automaticallyshuffling and cutting playing cards and delivering shuffled and cutplaying cards to the dispensing shoe without any human interventionwhatsoever once the playing cards are delivered to the shufflingapparatus. In addition, the shuffling operation may be performed as soonas the play of each game is completed, if desired, and simultaneouslywith the start of a new game, thus totally eliminating the need toshuffle all of the playing cards (which may include six or eight decks,for example) at one time. Preferably, the cards played are collected ina “dead box” and are drawn from the dead box when an adequate number ofcards have been accumulated for shuffling and cutting using the methodof the present invention.

Various embodiments include a computer controlled shuffling and cuttingsystem provided with a housing having at least one transparent wallmaking the shuffling and card delivery mechanism easily visible to allplayers and floor management in casino applications. The housing isprovided with a reciprocally slidable playing card pusher which, in thefirst position, is located outside of said housing. A motor-operatedtransparent door selectively seals and uncovers an opening in thetransparent wall to permit the slidably mounted card pusher to be movedfrom its aforementioned first position to a second position inside thehousing whereupon the slidably mounted card pusher is then withdrawn tothe first position, whereupon the playing cards have been deposited upona motorized platform which moves vertically and selectively in theupward and downward directions.

The motor driven transparent door is lifted to the uncovered positionresponsive to the proper location of the motor driven platform, detectedby suitable sensor means, as well as depression of a foot orhand-operated button accessible to the dealer.

The motor driven platform (or “elevator”) lifts the stack of playingcards deposited therein upwardly toward a shuffling mechanism responsiveto removal of the slidably mounted card pusher and closure of thetransparent door whereupon the playing cards are driven by the shufflingmechanism in opposing directions and away from the stack to first andsecond card holding magazines positioned on opposing sides of theelevator, said shuffling mechanism comprising motor driven rollersrotatable upon a reciprocating mounting device, the reciprocating speedand roller rotating speed being adjustable. Alternatively, however, thereciprocating and rotating speeds may be fixed; if desired, employingmotors having fixed output speeds, in place of the stepper motorsemployed in one preferred embodiment.

Upon completion of a shuffling operation, the platform is lowered andthe stacks of cards in each of the aforementioned receiving compartmentsare sequentially pushed back onto the moving elevator by suitablemotor-driven pushing mechanisms. The order of operation of the pushingmechanisms is made random by use of a random numbers generator employedin the operating computer for controlling the system. These operationscan be repeated, if desired. Typically, new cards undergo theseoperations from two to four times.

Guide assemblies guide the movement of cards onto the platform, preventshuffled cards from being prematurely returned to the elevator platformand align the cards as they fall into the card receiving regions as wellas when they are pushed back onto the elevator platform by themotor-driven pushing mechanism.

Upon completion of the plurality of shuffling and cutting operations,the platform is again lowered, causing the shuffled and cut cards to bemoved downwardly toward a movable guide plate having an inclined guidesurface.

As the motor driven elevator moves downwardly between the guide plates,the stack of cards engages the inclined guide surface of a substantiallyU-shaped secondary block member causing the stack to be shifted from ahorizontal orientation to a diagonal orientation. Substantiallysimultaneously therewith, a “drawbridge-like” assembly comprised of apair of swingable arms pivotally mounted at their lower ends, are swungdownwardly about their pivot pin from a vertical orientation to adiagonal orientation and serve as a diagonally aligned guide path. Thediagonally aligned stack of cards slides downwardly along the inclinedguide surfaces and onto the draw bridge-like arms and are moveddownwardly therealong by the U-shaped secondary block member, undercontrol of a stepper motor, to move cards toward and ultimately into thedealing shoe.

A primary block, with a paddle, then moves between the cut-away portionof the U-shaped secondary block, thus applying forward pressure to thestack of cards. The secondary block then retracts to the home position.The paddle is substantially rectangular-shaped and is aligned in adiagonal orientation. Upon initial set-up of the system the paddle ispositioned above the path of movement of cards into the dealing shoe.The secondary block moves the cut and shuffled cards into the dealingshoe and the paddle is lowered to the path of movement of cards towardthe dealing shoe and is moved against the rearwardmost card in the stackof cards delivered to the dealing shoe. When shuffling and cuttingoperations are performed subsequent to the initial set-up, the paddlerests against the rearwardmost card previously delivered to the dealingshoe. The shuffled and cut cards sliding along the guide surfaces of thediagonally aligned arms of the draw bridge-like mechanism come to restupon the opposite surface of the paddle which serves to isolate theplaying cards previously delivered to the dispensing shoe, as well asproviding a slight pushing force urging the cards toward the outlet slotof the dispensing shoe thereby enabling the shuffling and deliveringoperations to be performed simultaneously with the dispensing of playingcards from the dispensing shoe.

After all of the newly shuffled playing cards have been delivered to therear end of the dispensing shoe, by means of the U-shaped secondaryblock the paddle, which is sandwiched between two groups of playingcards, is lifted to a position above and displaced from the playingcards. A movable paddle mounting assembly is then moved rearwardly by amotor to place the paddle to the rear of the rearmost playing card justdelivered to the dispensing shoe; and the paddle is lowered to its homeposition, whereupon the motor controlling movement of the paddleassembly is then deenergized enabling the rollingly-mounted assemblysupporting the paddle to move diagonally downwardly as playing cards aredispensed from the dispensing shoe to provide a force which issufficient to urge the playing cards forwardly toward the playing carddispensing slot of the dealing shoe. The force acting upon the paddleassembly is the combination of gravity and a force exerted upon thepaddle assembly by a constant tension spring assembly. Jogging (i.e.,“dither”) means cause the paddle to be jogged or reciprocated inopposing forward and rearward directions at periodic intervals to assureappropriate alignment, stacking and sliding movement of the stack ofplaying cards toward the card dispensing slot of the dealing shoe.

Upon completion of a game, the cards used in the completed game aretypically collected by the dealer and placed in a dead box on the table.The collected cards are later placed within the reciprocally movablecard pusher. The dealer has the option of inserting the cards within thereciprocally slidable card pusher into the shuffling mechanism or,alternatively, and preferably, may postpone a shuffling operation untila greater number of cards have been collected upon the reciprocallyslidable card pusher. The shuffling and delivery operations may beperformed as often or as infrequently as the dealer or casino managementmay choose. The shuffling and playing card delivery operations are fullyautomatic and are performed without human intervention as soon as cardsare inserted within the machine on the elevator platform. The cards arealways within the unobstructed view of the players to enable theplayers, as well as the dealer, to observe and thereby be assured thatthe shuffling, cutting and card delivery operations are being performedproperly and without jamming and that the equipment is working properlyas well. The shuffling and card delivery operations do not conflict orinterfere with the dispensing of cards from the dispensing shoe, therebypermitting these operations to be performed substantiallysimultaneously, thus significantly reducing the amount of time devotedto shuffling and thereby greatly increasing the playing time, as well asproviding a highly efficient random shuffling and cutting mechanism.

The system may be controlled by a microcomputer programmed to controlthe operations of the card shuffling and cutting system. The computercontrols stepper motors through motor drive circuits, intelligentcontrollers and an opto-isolator linking the intelligent controllers tothe computer. The computer also monitors a plurality of sensors toassure proper operation of each of the mechanisms of the system.

XVI. CASINO COUNTERMEASURES

Some methods of thwarting card counters include using a large number ofdecks. Shoes containing 6 or 8 decks are common. The more cards thereare, the less variation there is in the proportions of the remainingcards and the harder it is to count them. The player's advantage canalso be reduced by shuffling the cards more frequently, but this reducesthe amount of time that can be devoting to actual play and thereforereduces the casino profits. Some casinos now use shuffling machines,some of which shuffle one set of cards while another is in play, whileothers continuously shuffle the cards. The distractions of the gamingfloor environment and complimentary alcoholic beverages also act tothwart card counters. Some methods of thwarting card counters includeusing varied payoff structures, such Blackjack payoff of 6:5, which ismore disadvantageous to the player than the standard 3:2 Blackjackpayoff.

XVII. VIDEO WAGERING GAMES

Video wagering games are set up to mimic a table game using adaptationsof table games rules and cards.

In one version of video poker the player is allowed to inspect fivecards randomly chosen by the computer. These cards are displayed on thevideo screen and the player chooses which cards, if any, that he or shewishes to hold. If the player wishes to hold all of the cards, i.e.,stand, he or she presses a STAND button. If the player wishes to holdonly some of the cards, he or she chooses the cards to be held bypressing HOLD keys located directly under each card displayed on thevideo screen. Pushing a DEAL button after choosing the HOLD cardsautomatically and simultaneously replaces the unchosen cards withadditional cards which are randomly selected from the remainder of thedeck. After the STAND button is pushed, or the cards are replaced, thefinal holding is evaluated by the game machine's computer and the playeris awarded either play credits or a coin payout as determined from apayoff table. This payoff table is stored in the machine's computermemory and is also displayed on the machine's screen. Hands with higherpoker values are awarded more credits or coins. Very rare poker handsare awarded payoffs of 800-to-1 or higher.

XVIII. APPARATUS FOR PLAYING OVER A COMMUNICATIONS SYSTEM

FIG. 2 shows apparatus for playing the game. There is a plurality ofplayer units 40-1 to 40-n which are coupled via a communication system41, such as the Internet, with a game playing system comprising anadministration unit 42, a player register 43, and a game unit 45. Eachunit 40 is typically a personal computer with a display unit and controlmeans (a keyboard and a mouse).

When a player logs on to the game playing system, their unit 40identifies itself to the administration unit. The system holds thedetails of the players in the register 43, which contains separateplayer register units 44-1 to 44-n for all the potential players, i.e.,for all the members of the system.

Once the player has been identified, the player is assigned to a gameunit 45. The game unit contains a set of player data units 46-1 to 46-6,a dealer unit 47, a control unit 48, and a random dealing unit 49.

Up to seven players can be assigned to the game unit 45. There can beseveral such units, as indicated, so that several games can be played atthe same time if there are more than seven members of the system loggedon at the same time. The assignment of a player unit 40 to a player dataunit 46 may be arbitrary or random, depending on which player data units46 and game units 45 are free. Each player data unit 46 is loaded fromthe corresponding player register unit 44 and also contains essentiallythe same details as the corresponding player unit 40 and is incommunication with the player unit 40 to keep the contents of the playerunit and player data unit updated with each other. In addition, theappropriate parts of the contents of the other player data units 46 andthe dealer unit 47 are passed to the player unit 40 for display.

The logic unit 48 of the game unit 45 steps the game unit through thevarious stages of the play, initiating the dealer actions and awaitingthe appropriate responses from the player units 40. The random dealingunit 49 deals cards essentially randomly to the dealer unit 47 and theplayer data units 46. At the end of the hand, the logic unit passes theresults of the hand, i.e., the wins and/or losses, to the player dataunits 46 to inform the players of their results. The administrative unit42 also takes those results and updates the player register units 44accordingly.

The player units 40 are arranged to show a display. To identify theplayer, the player's position is highlighted. As play proceeds, so theplayer selects the various boxes, enters bets in them, and so on, andthe results of those actions are displayed. As the cards are dealt, aseries of overlapping card symbols is shown in the Bonus box. At theoption of the player, the cards can be shown in a line below the box,and similarly for the card dealt to the dealer. At the end of the hand,a message is displayed informing the player of the results of theirbets, i.e., the amounts won or lost.

XIX. ALTERNATIVE TECHNOLOGIES

It will be understood that the technologies described herein for making,using, or practicing various embodiments are but a subset of thepossible technologies that may be used for the same or similar purposes.The particular technologies described herein are not to be construed aslimiting. Rather, various embodiments contemplate alternate technologiesfor making, using, or practicing various embodiments.

XX. REFERENCES

The following patents and patent applications are hereby incorporated byreference herein for all purposes: U.S. Pat. Nos. 6,579,181, 6,299,536,6,093,103, 5,941,769, 7,114,718, U.S. patent application Ser. No.10/622,321, U.S. Pat. Nos. 4,515,367, 5,000,453, 7,137,630, 7,137,629,U.S. patent application Ser. No. 11/063,311.

XXI. EXAMPLE EMBODIMENTS

Some embodiments may facilitate gaming on one of more mobile devices.Some embodiments may allow such gaming when a mobile device and/orcustomer is in a jurisdiction and/or area in which gaming (e.g.,gambling) is legal. Some embodiments may allow such gaming when a mobiledevice and/or customer is properly authorized and/or controlled. In someembodiments, various procedures and/or apparatus may be used to ensuresecurity, authenticity, and/or locations of a customer and/or device.Gaming may be facilitated, in some embodiments, over a cellular network,a wireless communication network, and/or any desired communicationnetwork. In some embodiments, when in location where such gaming isallowed, when a device is properly authorized and/or controlled, acustomer may operate a mobile device to place one or more wagers from awagering or other account over the communication network.

In some embodiments, gaming may include, for example, sports betting,casino betting, proposition betting, and/or other betting. In someembodiments, gaming may include gaming from a wagering account, a creditcard, using cash, on credit, and so on. In some embodiments,jurisdictions and/or areas in which gaming may be allowed may include,for example, casino floors, the state of Nevada, outside of hotel rooms,outside of residences, the city of Atlantic City, and so on. It shouldbe recognized that while some embodiments are described in terms ofsports wagering, cellular networks, and/or particular areas, that theseembodiments are given as examples only and that other embodiments mayinclude any desired types of wagering, any desired types ofcommunication networks, and/or any desired area(s).

Some embodiments may include technology configured to facilitate acustomer placing a bet over a communication network using a mobiledevice if the customer is in a location where placing the bet is legaland/or otherwise allowed (e.g., the state of Nevada). Some embodimentsmay include technology configured to prevent a customer from placing abet over a communication network using a mobile device if the customeris not in a location where placing the bet is legal and/or otherwiseallowed (e.g., may be prevented from wagering, may be prevented fromlogging into an account, may be logged out of an account when outside ofa legal gaming area, and so on). In some embodiments, gaming relatedservices may be provided and/or prevented outside of legal gaming areasas desired and/or as allowed in respective areas. Such gaming relatedservices may include providing betting lines, score updates, accountinformation, and so on. In some embodiments, a location of a mobiledevice may be used as a proxy for a location of a customer. Referencesto a location may be understood as a location of a mobile device (e.g.,a determined location, an approximate location).

Some embodiments may include one or more technologies that may be usedto determine a location of a customer and/or mobile device. One exampletechnology may include a geofencing technology. For example, a gamingoperator may determine that the customer is playing in Nevada by usinggeofence capability (e.g., Sprint geofencing services). In someembodiments, to implement a geofencing technology, a gaming operator maywork with Sprint, another geofencing provider, and/or a third partyprovider to ensure that desired locations are geofenced (e.g., the cityof Las Vegas, Reno, Tahoe and/or other gaming locations within the stateof Nevada and/or elsewhere). Customers may be allowed to engage inmobile gaming if they (e.g., a device they are using) are physicallyinside the approved boundaries. Customers may be prevented from engagingin mobile gaming if they are not physically inside the approvedboundaries. The service may be offered to Sprint customers and/orcustomers of any desired cellular and/or other network service provider.

Authentication Examples

Some embodiments may include an authentication method. Such anauthentication method may be designed to provide a desired level ofconfidence that a mobile device is not being accessed remotely, a mobiledevice has not been hacked, and/or a mobile device is at a locationwhere gaming is allowed. Such a method may be used to provide a level ofconfidence that a user is actually present at a mobile device, that theuser is actually using the mobile device, and/or that the user islocated at the location.

Although many different methods may be used, one example method mayinclude two example processes, for example: an initial sign up and/ordevice authorization (e.g., establish a link between a device and aplayer, and/or establish a wagering account), and an applicationsecurity handshake and/or continuous validation (e.g., occasionallyverify that software is unaltered and/or that a person associated withan account is still using a device). Such processes may be independent,dependent, a same process, different processes, arranged in any mannerand/or performed by any desired apparatus and/or people.

Sign Up and/or Authorization Examples

Some embodiments may include an initial sign up and/or deviceauthorization process. Such a process may include establishing a linkbetween a device and a player (e.g., an entry in a database thatidentifies that a particular player is associated with particulardevice). Such a process may include establishing a wagering account fora player (e.g., establishing an account into which a player may placemoney and/or from which a player may place wagers). Such a process mayallow a customer to sign up for a gaming service. After such a processis performed, a player and/or a device may be authorized to place wagers(e.g., over a communication network, with a particular gaming operatorthat performs at least a part of the process, and so on).

Some embodiments may include a customer signing up for a mobile gamingservice with a gaming operator. Such a signup process may be performed,at least in part, at a casino (e.g., by a casino employee, at a kiosk,in person, etc.), through a website (e.g., accessed by the mobiledevice, accessed by another device), in person (e.g., at a kiosk, at acasino), remotely (e.g., through a website, at a kiosk in a store).

In some embodiments, signing up for a mobile gaming service may includeopening a wagering account, and/or associating an account with anability to wager. For example, a new account may be established that auser may place money into and from which a user may access money toplace wagers. In some embodiments, such an account may include a bankaccount, a credit account, and/or any account hat may be created or havealready existed that may be associated with a gaming service.

In some embodiments, signing up for a mobile gaming service may includeidentifying a user and/or a mobile device that may access a gamingservice. For example, a user may be authorized to access the gamingservice using the device. A user may establish name, age, and/or otherinformation. A device may be established as meeting criteria, beingreliable, and/or having other traits.

In some embodiments, a sign up process may include determining customerinformation. Such customer information may be entered into a computingdevice by a customer, by an agent of a gaming service, and so on. Suchinformation may include a name, an age, a social security number, adriver's license number, a bank account number, an amount of money,and/or any information that may be desired and/or need to establish anaccount and/or allow wagering in a desired area. Such a computing devicemay include a device authenticator service providing device, which maybe referred to herein as a DAS.

In some embodiments, at least a part of a sign up process may berequired to be completed in person at a location of a gaming operatorand/or agent of a gaming operator. For example, in some embodiments, anentire sign up process may be required to be performed in person. Asanother example, a sign up of a person to verify eligibility to wager(e.g., verify age) may be required to be performed in person. In someembodiments, an application to use a mobile gaming service may berequired to be made in person and a customer may be required to providea valid proof of identification, proof of residence, social securitynumber, and/or any other desired proof of information to sign up for aservice. In some embodiments, a customer may be denied an application tosign up for a mobile gaming service if they are under 21 years of age,do not meet a residency requirement, do not provide proper proof ofidentification, do not meet a sobriety requirement, and/or do not meetany other desired requirement.

In some embodiments, a sign up process may include establishing anability for a user to access an account in the future. For example, ausername and password may be established. In some embodiments, ausername and mac address or phone number of a particular device may beused. In some embodiments, mac address or phone number of a device andpassword may be used. In some embodiments, a database may be establishedthat includes entries for a user information, a device information,and/or any combination of user and/or device information that may beused to determine future access to a gaming service.

Some embodiments may include a minimum initial balance and/or depositinto a wagering account to sign up for a gaming service. In someembodiments, for example, a customer may be required to provide aminimum of $100.00 in cash to be placed in a new account establishedwith the gaming operator in order to sing up for a mobile gamingservice. It should be recognized that $100.00 is given as a non-limitingexample and that other embodiments may include any minimum as desired(e.g., 1 cent, 10 dollars, 1 million dollars). It should be recognizedthat cash is given as a non-limiting example and that other embodimentsmay allow transactions to and/or from an account in a form of cash,personal checks, cashier's checks, wire transfers, money orders, debitcards, credit cards, electronic transfers of money at a casino cage,and/or any desired method. In some embodiments transfers to and/or froman account including initial and/or subsequent transfers may be made ata same location as a sign up process, through an agent of a gamingoperator, on a website, and so on as desired.

Some embodiments may restrict a sign up process to being performed by acustomer. For example, in some embodiments, no agents of a customer maybe allowed to sign a customer up for a gaming service. In someembodiments, a sign up may be restricted to normal business hours of asports book and/or other place of business of a gaming operator. In someembodiments, an agent of a customer may sign the customer up and/or asign up may be performed at any time.

Some embodiments may include verifying a mobile device for use with agaming service. Such verification may include, for example, determiningan authenticity of software, determining an operating system version,determining a communication network, and/or any other actions asdesired. Such verification may be performed in person by an agent of agaming operator, remotely by software (e.g., software on the mobiledevice, software on a kiosk such as a kiosk to which a mobile device maybe attached through a USB port and/or other wired and/or wirelesscommunication method).

In some embodiments, a customer may physically provide a mobile deviceto an agent of a gaming operator for verification. In some embodiments,software on the gaming device may be executed to perform verification.In some embodiments, a third party and/or second machine may performverification.

An entity performing verification may determine that a device is runningan approved operating system. One example of an operating system thatmay be approved may include Android OS 2.2. Such a determination may bemade by reading a memory location, comparing files, comparing anoperating system with a listing of approved operating systems, and soon.

An entity performing verification may determine that a device is runningon an approved communication network. One example communication networkthat may be approved may include a Sprint network. Such a determinationmay be performed by reading a memory location, contacting Sprint tocompare a device identifier, comparing a communication network with alisting of approved communication networks, and so on.

An entity performing the verification may determine that an operatingsystem running on the device is approved operating system for thecommunication network that the device is running on. For example, such adetermination may include a determination that the device has not beenrooted. Such a determination may include comparing a running operatingsystem with a listing of approved operating systems for thecommunication network and device.

An entity performing verification may determine that a device is runningand/or storing any desired programs and/or is not running and/or storingany undesired programs. For example, the entity may determine that thedevice is running an approved antivirus program. As another example, theentity may determine that the device is not running any undesiredmalware, and/or remote access technologies. Various examples ofdetermining whether a device is remotely controlled are given elsewhereherein. Such a determination may include a search of a memory, acomparison of running and/or stored programs with a listing of approvedand/or unapproved programs, and so on.

Some embodiments may include installing and/or enabling one or moreservices on a mobile device. Such installation and/or enabling may beperformed in response to a verification of a device and/or a signing upof a user for a service. Such installing and/or enabling may beperformed by an agent of a gaming operator, by a kiosk, by a gamingoperator computing device, by a customer, by software running on themobile device, and so on.

In some embodiments, an Android wrapper application and/or an AIR mobilegaming client may be installed on a mobile device. It should berecognized that such example programs are given as non-limiting examplesonly and that other embodiments may include any desired programs and/orno programs at all. For example, in some embodiments, rather than anAndroid wrapper application, a Win32 wrapper application may beinstalled, an Apple application may be installed, and so on. In someembodiments, a customer may be provided with information on how toreinstall any desired software if a problem arises.

Some embodiments may include verifying proper authentication and/or signup. Such verification may be performed by any entity desired (e.g., acustomer, a program, an agent of a gaming operator, a kiosk). Suchverification may include comparing checksums and/or MD5 and/or SHA-2hashes of files, program names, and so on. Such verification may includea verification by signing into an account and/or gaming service usingthe mobile device and/or performing any desired actions with the mobiledevice.

In some embodiments, after such a process (e.g., in response tosuccessfully completing one or more actions of such a process), acustomer may be and/or a device may be approved for gaming. A customer,for example, may be able to access a wagering account and/or placewagers through a gaming service using an approved device (e.g., thedevice and/or any approved device).

In some embodiments, a customer may be associated with a device for usewith a gaming service. For example, if a customer signs up with a deviceand the device is verified, the verified device, and the customer may belinked so that the customer may use the device with the gaming service.For example, a database entry identifying such a link may be made (e.g.,a username of the customer and/or mac address/phone number of the devicemay be identified as linked). In some embodiments, the customer may beprevented from using other devices with the service (e.g., unless thecustomer signs those devices up and becomes associated therewith aswell). In some embodiments other customers may be prevented from usingthe device with the gaming service (e.g., unless the other customersbecome associated with the device).

In some embodiments, a player may be able to access an account and/orwager through a wagering service using any device that has beenactivated. For example, a user may sign on to a wagering service usingan established username and/or password using any device that has beenverified for use with a gamine service by the user and/or any otheruser. In some embodiments, separate databases of approved devices andapproved users may be kept, and any combination may be allowed to use awagering service.

It should be recognized that such a process is given as a non-limitingexample only and that other embodiments may include different, same,more, fewer, none, and so on such processes. Such processes may includesame, different, alternative, fewer, more, differently ordered, and soon actions.

Security Handshake and/or Continuous Validation Examples

In some embodiments, an application security handshake may include amultisystem secure authentication protocol that may facilitatecompliance with one or more regulatory requirements. For example, one ormore actions and/or devices may provide reasonable assurances that amobile device accessing a gaming service is at an approved gaminglocation at a time of a wager by utilizing a location service toretrieve the device's location (e.g., on a regular basis), validating alocation of a device in response to one or more requests to a gamingservice (e.g., every request). As another example, one or more actionsand/or devices may provide reasonable assurances that a mobile device isbeing used in person and not being remotely controlled by, for example,validating on a polled interval that some (e.g., all except one)external interfaces to the device are disabled before allowing access toa gaming service. As another example, one or more actions and/or devicesmay provide reasonable assurances that a gaming application executed bya mobile device includes an authentic application by using a multistagehashing protocol to send application and OS signatures to the deviceauthenticator service before allowing betting. As another example, oneor more actions and/or devices may provide reasonable assurances thatapproved client versions are authorized to be used to place wagers bystoring approved application hashing values on an internal databasewhich is not accessible outside a firewall. As another example, one ormore actions and/or devices may provide reasonable assurances thatfollow best practices regarding failed login attempts, session timeouts,etc. by defining session timeouts for each system connection the deviceis. As yet another example, communications may be secure by using SSLHTTPS protocol for communications that go over the Internet, and/orusing application signature validation between processes on a device.

Some embodiments may include one or more actions that may be designed toprovide some level of confidence regarding location, security,authenticity and/or any desired characteristics at a beginning of agaming session, throughout a gaming session, and/or at points during agaming session. In some embodiments, such actions may include a securityhandshake and/or a continuous validation process. A continuousvalidation process may include a process that periodically validatessomething, that occasionally validates something, that continuouslyvalidates something, that validates something at least one time after ahandshake, that validates something upon an action, and so on.

Initial Validity with Service Provider Examples

Some embodiments may include an initial security process. Such aninitial security process may be referred to as a handshake herein. Insome embodiments, a handshake may include a multisystem secureauthentication protocol. Such a process may provide reasonableassurances that the mobile device is in a location where gaming ispermitted at and/or near the time of gaming. Such a process may providereasonable assurances that the mobile device is being used in person andnot being remotely controlled at and/or near a time of gaming. Such aprocess may provide reasonable assurances that software running on amobile device includes an authentic application of a gaming operator.Such a process may provide reasonable assurances that that only approvedclient versions are authorized to be used to make wagers through agaming service. Such a process may provide reasonable assurances thatsome and/or all external interfaces (e.g., Bluetooth, non-gamingoperator provided Wi-Fi, USB/DOCK) on the devices may be disabled toprevent remote connections. Such a process may use multilayerauthentication. Such a process may include use of a soft tag and/orother location determination to locate the device. Such a process may beperformed at a start of an application on a device, periodically by adevice, upon installing of an application, in response to a bet beingrequested and/or placed, occasionally, continually, when a connection toa gaming operator is established, before a bet is placed, and/orwhenever desired. For example, in some embodiments, an application maybe programmed to perform at least a part of such a process when theapplication is started (e.g., selected to be executed on a mobiledevice). Examples of such processes given herein are non-limitingexamples. Other embodiments may include no such process, a process withmore, fewer, different, same, and/or differently ordered actions. One ormore actions of such a process may be performed by a wrapperapplication, a main application, and/or any other component.

Some embodiments may include determining whether a device is approvedfor use with a gaming service. In some embodiments, determining that adevice has been approved for use with a gaming service may includecomparing information about the device with a listing of devices thathave been approved (e.g., a database of approved phone numbers, macaddresses, etc.). In some embodiments, information identifying thedevice may be transmitted to a gaming service so that the gaming servicemay make such a comparison and/or determine in any desired way whetherthe device is approved. A gaming service may receive such identifyinginformation and in response to such receipt, determine if the device isapproved (e.g., if the device was previously registered, if the deviceinformation is in a database that identifies approved devices, etc.). Insome embodiments, in response to a start of a gaming application, thegaming application may transmit a request to a gaming operator to verifythat the device was previously approved for using the gaming service. Insome embodiments, a wrapper application (e.g., an android wrapperapplication, a win32 wrapper application, a wrapper application that amain application communicates with, and so on) may transmit the requestto a component of a gaming service (e.g., a device authenticatorservice). In some embodiments, the request may include a phone number,mac address and/or any other desired identifying information. In someembodiments, the component of the gaming service may receive therequest, and in response to receiving the request verify that the devicehas been previously approved for gaming. In some embodiments, thecomponent may transmit an indication of such verification to the mobiledevice. In some embodiments, a request from the mobile device may not betransmitted, but rather a communication from the mobile device may beinterpreted as a request (e.g., an initial communication of a gamingsession).

Some embodiments may include determining whether a device is/was locatedat a location where gaming is allowed. In some embodiments, determiningthat a device is/was located at a location where gaming is allowed mayinclude comparing information about where a device is/was located to alist of approved gaming locations. Some embodiments may includetransmitting a request from a mobile device to a gaming service toverify that a location is approved. Such a request may include therequest transmitted to verify that the device is approved for gaming. Insome embodiments, a separate request may not be transmitted, but rather,a request for authentication may be interpreted as a request forlocation and/or a location may be verified without any request at all.In response to receiving such a request and/or determining that alocation should be verified, a component of a gaming service mayfacilitate a determination of whether the location is approved. Forexample, a DAS may send a request to a mobile location service to tracka device location. Examples of such device tracking and/or locationdetermination are described elsewhere. Some embodiments may includedetermining that a device is/was an approved location. Such adetermination may be sent back to the mobile device in some embodiments.Such a determination of a location may be made in response to receivingthe determination that the device is authenticated.

Some embodiments may include determining that a user is approved to usea gaming service. In some embodiments, determining that a user isapproved to use a gaming service may include requesting user informationfrom the user and/or requesting verification of such user information.For example, a user may be prompted for a username and password. Suchusername and password may be authenticated by a gaming service. Such adetermination may include determining that the user is approved to use aparticular mobile device and/or the gaming service at large. Such adetermination may be made in response to a user entering identificationinformation, a determination that a device is approved, a determinationthat a device is in an approved location, and/or in response to anydesired event.

Some embodiments may include determining that application softwareexecuted by a mobile device is approved for use with a gaming service.In some embodiments, determining that application software is approvedfor use with a gaming service may include verifying the applicationsoftware verifying a version of the software, and/or verifying that thesoftware is unmodified from an approved version.

One example method of determining that application software is approvedmay include a comparison of hashes and/or other characteristics ofapplication software. For example, in some embodiments a wrapperapplication and/or other software component may determine an applicationsignature hash (e.g., a hash of one or more application files and/orother files). In some embodiments, such a wrapper application and/orother software component may generate a random number. In someembodiments, such a wrapper application and/or other software componentmay determine a timestamp (e.g., the current time, a relatively recenttime). In some embodiments, such a wrapper application may determine ahash, which may be referred to as the App Hash herein, of the timestamp,the random number, and the application signature hash. Some embodimentsmay include transmitting (e.g., by the wrapper and/or other softwarecomponent) the timestamp, random number, and the App Hash to the gamingservice (e.g., to a device authenticator service) from the mobiledevice. In some embodiments, a component of the gaming service (e.g., adevice authenticator service) may validate that the timestamp is in apredetermined threshold of time (e.g., 5 minutes, 30 seconds, 1 hour)from another time (e.g., a current time, a time when information aboutthe App Hash is received, a recent server time, and so on). In someembodiments, the gaming service component may validate the App Hash.Such validation may include creating a comparison hash of the receivedtimestamp, the received random number, and an approved applicationsignature hash. Multiple comparison hashes may be created for multipleapproved applications. Such a validation may include comparing the AppHash with the comparison hash or hashes. If a comparison hash and theApp Hash are equal, then the App Hash may be determined to be valid. Ifthey are not equal, then the App Hash may be determined to be invalid.In some embodiments, a determination that the App Hash is valid may be adetermination that the application software is approved for use with thegaming service. A determination that the App Hash is invalid may includea determination that the application software is not approved for usewith the gaming service.

It should be recognized that such an example of hash comparison is givenas a non-limiting example only. Other embodiments may include anydesired method or no method of such validation. For example, checksumsmay be used, random numbers may not be used, time stamps may not beused, additional information may be used, and so on.

In some embodiments, in response to determining that the applicationsoftware is approved for use with the gaming service, an indication ofsuch approval may be transmitted to and/or received by the mobiledevice. In some embodiments, a gaming service component (e.g., deviceauthenticator service) may determine a client key (e.g., a unique clientkey, a random number). Such a client key may be used for one or morefuture transactions. Such a client key may uniquely identify the mobiledevice and/or that the mobile device has passed one or moreauthentication steps. Such a client key may be transmitted to the mobiledevice in response to a determination that the application software isapproved for use with the gaming service. Such a key may be stored in adatabase (e.g., a database that associated it with the mobile device).

Some embodiments may include determining that an operating system isapproved for use with a gaming service. In some embodiments, determiningthat an operating system is approved for use with a gaming service mayinclude verifying a version of an operating system, verifying that anoperating system is unmodified, and/or any desired actions.

One example method of determining that the operating system is approvedmay include a comparison of hashes. For example, in some embodiments awrapper application and/or other software component may determine a hashof one or more operating system files and/or components and the clientkey. The wrapper application and/or software component may transmit thehash, the previously determined timestamp, the previously determinedrandom number, the client key, and device identifying information (e.g.,a phone number, mac address) to a component of the gaming service (e.g.,a device authenticator service). In some embodiments, a component of thegaming service (e.g., a device authenticator service) may validate thatthe timestamp is in a predetermined threshold of time (e.g., 5 minutes,30 seconds, 1 hour) from another time (e.g., a current time, a time wheninformation about the App Hash is received, a recent server time, and soon). In some embodiments, a component of the gaming service (e.g., adevice authenticator service) may validate that the client key is themost recent one sent to the mobile device identified by the identifyinginformation (e.g., by comparing the client key with a client key storedin a database keyed by the identifying information). In someembodiments, a component of the gaming service (e.g., a deviceauthenticator service) may validate that the received hash. Suchvalidation may include creating a comparison hash of the client key andapproved operating system files and/or components. Multiple comparisonhashes may be created for multiple approved operating systems. Such avalidation may include comparing the received hash with the comparisonhash or hashes. If a comparison hash and the received hash are equal,then the comparison hash may be determined to be valid. If they are notequal, then the comparison hash may be determined to be invalid. In someembodiments, a determination that the received hash is valid may be adetermination that the operating system is approved for use with thegaming service. A determination that the received has his invalid may bea determination that the operating system is not approved for use withthe gaming service.

It should be recognized that such an example of hash comparison is givenas a non-limiting example only. Other embodiments may include anydesired method or no method of such validation. For example, checksumsmay be used, random numbers may not be used, time stamps may not beused, device information may not be used, client keys may not be used,device information may be obtained from another source, additionalinformation may be used, and so on.

One further example of a determination that an operating system isapproved for use with a gaming service may include another method ofcomparing one or more hashes. For example, in some embodiments, anapplication (e.g., a wrapper application) may generate a hash of one ormore portions of one or more operating system files. Such a portion mayinclude less than an entirety of a section. In some embodiments,generating such a hash may include generating a hash of the one or moreportions along with a length of the one or more operating system files.For example, a hash of a beginning and end of a section (e.g., a file)of an operating system that manages control of communication interfacesalong with a length of the section may be created. The beginning and endmay include a first 128 bytes and last 128 bytes and/or any otherdesired size of a portion. In some embodiments, such a hash may betransmitted to a gaming service for comparison with one or more approvedhashes. It should be recognized that any portion or portions of asection may be used in various embodiments, in addition to and/or as analternative to a beginning and/or end.

In some embodiments, such hashing of portions and lengths rather than anentire file may provide reasonable assurances of an unaltered file. Suchassurance may be provided because it may be unlikely that a file may bealtered and yet result in a same hash result when a beginning, end andlength are hashed. Such a method may allow for faster verification thana method that includes a hash of an entire section. It should berecognized that while hashing is given as an example, that otherembodiments may include any desired transformation and/or notransformation at all (e.g., a comparison of actual files).

In some embodiments, a gaming service maybe updated to include newlyapproved comparison hashes as a gaming service determines that newoperating systems and/or modified operating systems should be approvedfor use with the gaming service.

Some embodiments may include transmitting information from a componentof a gaming service to a mobile device in response to a completion ofsuch a process, to complete such a process, as part of such a process,in response to verifying the operating system, in response to anotheraction of such a process, and so on. Some embodiments may includestoring information identifying that such a process has succeeded. Forexample, some embodiments may include determining a device sessionidentifier. Such an identifier may include a unique identifier that maybe used to identify a gaming session between the gaming service and themobile device. Such a device session identifier may be associated withthe mobile device (e.g., stored in a database). Such a device sessionidentifier may be time stamped (e.g., with the previously determinedtime stamp, with a time relative to the determination of the devicesession identifier, and so on). Such a device session identifier mayinclude a random number. Such a device session identifier may betransmitted to a mobile device and/or stored in a location to identify asuccess of such a process. Such a device session identifier may bereceived by a wrapper application and/or other software component. Sucha device session identifier may be stored by the mobile device (e.g., inan encrypted form, in local storage, in memory, in a location reservedfor the mobile gaming application and/or a component thereof, in alocation reserved for the wrapper application and/or other softwarecomponent, in allocation only accessible by a desired application, andso on). Such a device session identifier may be transmitted with futurerequests from the device to identify that a process has completedsuccessfully. When a future request is received by a component of agaming service, a comparison of a received device session identifier maybe made to ensure that a valid device session identifier is receivedwith the request. Accordingly, such a check may ensure that only devicesthat have completed such a process can access a gaming service.

In some embodiments, if a part of this process fails, the phone may beconsidered unauthorized by the server and requests (e.g., gaming relatedcommunications) may be refused. It should be recognized that such anexample process is given as a non-limiting example only. Otherembodiments may include differently ordered actions, differentcomponents, no actions, more actions, fewer actions, and so on. Anyaction may be taken in response to any other action being successful(e.g., a determination of application software being valid may cause adetermination as to whether or not operating system software is valid tooccur).

Device and/or User Security

In some embodiments, at least a part of such an initial validity and/orhandshake may be performed by a wrapper application. If such an initialprocess is completed successfully, a main application may be executed(e.g., by the wrapper application). Such a main application may performa device and/or user security process. In other embodiments, a wrapperapplication may perform any desired other actions (e.g., a belowprocess), a single application may be used, any arrangement of programsmay be used, and so on.

Some embodiments may include a process for providing a level ofassurance as to a device and/or user security. In some embodiments, sucha process may be performed at a start of a gaming application,throughout an execution of a gaming application, in response to alogging into a gaming service, in response to a completion of an initialhandshake and/or other initial process, parallel to an initial handshakeand/or initial process, before an initial handshake and/or initialprocess, as part of an initial handshake and/or initial process, and/oras otherwise desired. Such a device security process may includedetermining that a device is locally used and/or preventing a devicefrom being remotely accessed.

Some embodiments may include establishing a connection between a maingaming application and a wrapper application. Such a connection mayinclude a socket. Such a connection may include a shared memory space.Some embodiments may include a wrapper application opening a socket.Such a socket may only be accessible by software executed on the mobiledevice. In some embodiments, a main application may connect to thesocket and/or memory space. The socket and/or memory space may be usedfor communication between the applications.

Some embodiments may include verifying that a connection betweenapplications and/or shared identifiers are valid. For example, in anAndroid environment, a lock file may be written to a data store of afirst application (e.g., a wrapper application). An Android operatingsystem may prevent a second application (e.g., a main application)running on the mobile device from accessing the first application unlessthe application has been signed by a same application signature. Asecond application may attempt to delete the lock file form the firstapplication's data store. In some embodiments, if the applicationsproperly share the same signature, the deletion may occur. The firstapplication may verify that the deletion has occurred. If the deletionhas occurred, the first application may be confident that the secondapplication shares a valid signature with the first application. Asanother example, some embodiments may verify that the only twoapplications running under a particular user identifier are the twoapplications and/or other gaming applications that are approved. In someembodiments a verification that the two and/or more applications arerunning under a same user identifier. The first application may share adevice session identifier with the second application in response to oneor more such determinations.

Some embodiments may include determining that a user is authorized touse a gaming service. For example, some embodiments may includesoliciting user information. Such a solicitation may be performed by agaming application (e.g., a wrapper application, a main application,etc.) running on a mobile device. For example, a user may be solicitedfor a username and password. A username and password may be received bya gaming application in response to a user entering such informationinto a mobile device. Some embodiments may include transmitting suchinformation from a gaming application to a component of a gamingservice. For example, in some embodiments, such information may betransmitted to a gateway device. In some embodiments, an accountinformation (e.g., account number, username, password, pin, etc.) may betransmitted to such a gateway and/or other device. In some embodiments,such a transmission may include a transmission of a device sessionidentifier and/or any other information that may be used to identify adevice, a session, a previously authentication of information, and/ortrack any desired information. Various actions may be performed by agaming application (e.g., a wrapper application, a main application,etc.) running on a mobile device.

In some embodiments, a gateway and/or other component of a gamingservice (e.g., middleware, servers, etc.) may enable a communicationsession (e.g., HTTP session, HTIP session) for a mobile device. Thegateway and/or other component may associate a device identifier with acommunication session. For example, such a communication session mayonly be usable when it is accessed using the device identifier unless adifferent or other identifier is associated with the session. In someembodiments, a communication session may be defined by one or morevariables (e.g., a port number, an id number). Such variables may beshared with a mobile device and future communications may include suchvariables.

Some embodiments may include determining that a mobile device is/was ata location that is approved for gaming. Such a determination may be madein response to receiving account information from a mobile device by agaming service. In some embodiments, a device session identifier may betransmitted from a gateway and/or other component to a differentcomponent for verification (e.g., to a device authenticator service).Such a device authenticator service may verify the device sessionidentifier and determine if the device session identifier is associatedwith an approved location. If the device session identifier isassociated with an approved location, the device authenticator servicemay transit an indication of approval to the gateway. In someembodiments, a single device may perform such approval actions. Itshould be recognized that such a process of determining whether a deviceis/was at an approved location is given as an example only. For example,in some embodiments a device itself may determine whether it is in anapproved location, a gateway and/or other component may determinewhether the device is in an approved location, any device may determinewhether the device is in an approved location, a current location may bedetermined, an old location may be used, and so on. Various examples ofdetermining locations and/or storing location information are givenherein. None of such examples are limiting.

In some embodiments, a gaming service may validate user information.Such a validation may occur in response to receiving the userinformation, in response to determining that the device is/was in anapproved location, in response to another event, and so on. For example,in some embodiments, a gateway and/or other component may transmit useraccount information to another component of a gaming service (e.g.,device authenticator service, mobile gaming service, etc.). Such anothercomponent may validate the account information (e.g., determine thatusername and password are accurate, compare information to informationin a database, etc.).

In some embodiments, if the information is validated, such a componentmay transmit an indication of such validation to a gateway and/or othercomponent. Such an indication may include a wagering session identifier.A wagering session identifier may be determined in response to adetermination that the information is valid. Such a wagering sessionidentifier may include a unique identifier. Such a wagering sessionidentifier may include a random number. A gateway and/or anothercomponent may receive such an identifier. Such a gateway and/or othercomponent may associate such an identifier with a communication sessionfor the mobile device (e.g., further communication may require such anidentifier unless it is changed). In some embodiments, a mobile device(e.g., a main application and/or wrapper application) may be notified ofsuch an identifier and/or a success of an authentication of a user. Sucha mobile device application may store such an identifier for use infuture communication. Future requests from a mobile device may includesuch an identifier.

In some embodiments, such validation may occur only if the device is/wasat an approved location. If the device does not pass a location check,the device may be prevented from gaming and such a login may not beperformed. In other embodiments, such a login may continue regardless ofthe location of the device. In some embodiments some features of agaming service may be disabled if the location check does not pass.

It should be recognized that while some embodiments have been describedas having separate processes (e.g., an initial handshake and/or auser/device security process) and/or separate applications (e.g., awrapper application and a main application) that various embodiments mayinclude a single process and/or a single applications, multipleprocesses, and/or applications, differently ordered and/or interactingapplications and/or processes, and so on.

In some embodiments, after such an initial handshake process and/or adevice and/or user security process, one or more variables may bedefined. For example in the example methods, a wagering sessionidentifier and/or communication session may be defined by the userand/or device security process, and/or a device session identifier maybe defined by an initial handshake process. Such variables may bechecked, updated, changed, tracked, and so on. Such variables may berequired for further communication from the mobile device to be allowedto access gaming services. For example, if communication is received bythe gaming service without such variables being valid, the communicationmay be ignored and/or not allowed to form a wager. Such variables aregiven as non-limiting examples only. Other embodiments may includedifferent variables, additional variables, no variables, differentapplications, and so on as desired.

It should be recognized that various security processes and/orapplications are given as non-limiting examples only. Other embodimentsmay include any and/or no processes in any order, with any actions, andso on. Such processes may include additional, fewer, different, same,differently ordered, and so on actions.

On Going Validity Examples

Some embodiments may include one or more actions related to maintainingsecurity, maintaining location information, and/or creating some levelof assurances that some requirements are met. For example, someembodiments may include continuous, periodic, occasional, randomly, ondemand, in response to action, and/or other actions. Such actions mayinclude location checks, device checks, user checks, and so on.

Variable Maintenance Examples

In some embodiments, such actions may include maintaining one or morevariables, expiring one or more variables, redefining one or morevariables, and so on. Some embodiments may include actions related tovariables defined in other security processes, such as those discussedabove. For example, a device session identifier, a gaming sessionidentifier, and a communication session may be used in some embodiments.Such variables may have limited valid lifetimes, may be redefinedperiodically, may expire after some time, may be required tooccasionally redefined, and so on. For example, in some embodiments, adevice session identifier may be valid for about 30 seconds, about 3minutes, about 5 minutes, about 10 minutes, about 1 hour, and/or anydesired time. As another example, a gaming session identifier may bevalid for about 30 seconds, about 3 minutes, about 5 minutes, about 10minutes, about 1 hour, and/or any desired time. As yet another example,a communication session may be valid for about 30 seconds, about 3minutes, about 5 minutes, about 10 minutes, about 1 hour, and/or anydesired time. New variables may be defined in a similar fashion to theiroriginal definitions (e.g., by a device authenticator service, by amobile gaming service, by a gateway, by a server, by another component,using hash values, using checksums, using random numbers, usingtimestamps, and so on).

Various examples of defining such variables are given elsewhere, but itshould be recognized that such examples are non-limiting and thatsimilar, different, same, alternative, and so on methods may be used toredefine and/or define any same and/or different variables as desired.It should be recognized that variables, and time frame for validity aregiven as non-limiting examples only and that other methods may includeno, other, same, different, and so on variables; no, different, same,and so on methods of maintaining security and/or other characteristics,my use different time frames, my use random time frames, may randomlyrequire redefinition, may require definition upon and event (e.g., awager request), and so on.

Characteristic Examples

In some embodiments, one or more actions may be related to validatingone or more characteristics of a device and/or user of a device. Someembodiments may include actions related to such characteristics (e.g.,location, user identity, lack of external control of device, etc.). Forexample, in some embodiments, a disabling of external access to a mobiledevice may be validated, a location of a device at an approved gaminglocation may be validated, a user identify information may be validated,one or more variables being valid may be determined, and so on. In someembodiments, such validation may occur periodically, randomly, ondemand, in response to an action, as desired, and so on.

For example, some embodiments may include validating that some and/orall external communication (e.g., except communication used to access agaming service such as a mobile phone network) are disabled. Someembodiments may include a gaming application executed by a mobile devicequerying an operating system of a mobile device. For example, a mainapplication may transmit a query to a wrapper application. The wrapperapplication may query the operating system. In some embodiments, inresponse to such a query, the operating system may determine if anyinvalid interfaces are enabled and return such information to thewrapper application and/or main application. In response to suchinformation the validation may fail (e.g., if unapproved interfaces areenables) and/or succeed (e.g., if no unapproved interfaces are enabled).Some examples of interfaces that may not be approved may includeBluetooth, Wi-Fi, docking port, and/or other interfaces. Such avalidating may occur continuously, periodically (e.g., every 5 seconds,every 15 seconds, every minute, every 5 minutes, every hour, etc.),randomly, on demand, and so on.

As another example, some embodiments may include validating that amobile device is/was at a location that is associated with allowedgaming. Some embodiments may include a component of a gaming systemmaking such a check independent of actions on the mobile device. Someembodiments may include the mobile device checking such a status (e.g.,by querying a gaming system and/or other location system). In someembodiments, a component of a gaming system (e.g., a deviceauthenticator service) may run checks on the location of the mobiledevice. Such a component may update a database with the check results,may enable or disable communication with a mobile device, features of agaming service in response to such results, may notify a mobile device(e.g., to disable a feature of the device and/or display in indicator)and/or user in response to such results. Such a check may be performedcontinuously, periodically (e.g., every 30 seconds, every 5 minutes,every 10 minutes, every 15 minutes, every hour, etc.), on demand, inresponse to an event, and so on. In some embodiments, such locationchecks may be made more frequent when a mobile device is near an edge ofan approved area than when the device is far from an edge of an approvedarea. For example, in some embodiments, a check may be performed every 5minutes if a device in a previous check was near a border of a state,every 10 minutes if a device was near an edge of an approved area butfar from an edge of a state, and every 15 minutes if a device was notnear a border of a state or a border of an approved area. Variousexamples of location determination are given elsewhere herein. It shouldbe recognized that examples of location checking are given asnon-limiting examples only and that other embodiments may include no,different, same, and so on methods.

As yet another example, some embodiments may include determining whetheruser information is valid and/or whether a session or another variableis valid. For example, some embodiments may include transmitting arequest from a mobile device to a component of a gaming service (e.g., agateway). Such a request may include user information for validation,and or a request to verify that some variable is valid. For example, arequest may request that the gateway verify that a device authorizationsession is valid. Such request may be processed (e.g., by a deviceauthenticator service) and a response may be transmitted to the mobiledevice. Such a check may be performed continuously, periodically (e.g.,every 30 seconds, every 5 minutes, every 10 minutes, every 15 minutes,every hour, etc.), on demand, in response to an event, and so on.

Various examples of characteristics and methods validation should berecognized as non-limiting. Other embodiments may include no, similar,different, same, alternative, and so on methods and/or characteristics.

Event Examples

In some embodiments, one or more actions may be related to validatingone or more characteristics of a device, user, and/or variable inresponse to an event. For example, in some embodiments, when acommunication is received from a mobile device, a gaming service mayperform such one or more actions. In some embodiments, suchcommunication may include a request to place a wager, a request to viewavailable wagers, a request to view an account, and so on. For example,in some embodiments, in response to a request being made to and/orthrough a gateway and/or other component of a gaming service (e.g.,after initial login) one or more actions may be taken.

Some embodiments may include transmitting a request from a mobile deviceto a gaming service. For example, a wrapper application and/or mainapplication may transmit a request to a gateway, and/or other componentof a gaming service. Such a request may identify any desired variables(e.g., a communication session, a device session identifier, a gamingsession identifier, a client key, and so on). Such a request may includea request to take a gaming related action, such a request may include apolling of a gaming service to determine current information (e.g.,current games, current scores, account history, current account values,etc.). Some embodiments may include periodic, random, constant, etc.polling. In some embodiments, such polling may not initiate suchvalidation actions.

Some embodiments may include receiving such a request by a component ofa gaming service. For example, such a request may be received by agateway and/or other component of a gaming service. In some embodimentsa determination may be made that such a request triggers one or morevalidation actions (e.g., all request may trigger such actions, every Xrequest may trigger such actions, randomly some requests may triggerssuch actions, certain types of requests may triggers such actions, adetermination may be made the request is not a polling request, adetermination may be made that the request is a request to place awager, a request every Y minutes may trigger such actions, etc.).

A gateway or other device may perform any desired actions in response toreceiving such a request and/or determining that such actions should beperformed. For example, in some embodiments, a gateway or othercomponent may determine that a communication session identified by arequest is properly associated with the device from which it is received(e.g., by querying a database).

As another example, in some embodiments (e.g., if the communicationsession check passes) a gateway and/or other component may validate adevice session and/or location information. For example, in someembodiments, a gateway and/or other component may transmit a request forvalidation of a device session and/or location to a device authenticatorservice. A database of information may be queried to determine if one ormore variables are valid (e.g., if a device session identifierassociated with the device is valid, have not expired). A database ofinformation may be queried to determine if a mobile device was lastdetermined to be at a location where gaming is allowed. In someembodiments, a new location of the device may be determined. If suchchecks pass, a timestamp of a last valid check may be updated. Suchinformation may be returned to a gateway and/or other component. Itshould be recognized that such examples of validation are given asexamples only and that other methods may include different components,characteristics, and/or actions.

As yet another example, in some embodiments, if a validation is made ofone or more characteristics from a device authenticator, a gatewayand/or other component may validate any desired characteristic and/orvariable with any components. For example, a gaming session identifiermay be validated with a component of a gaming service. Such a component(e.g., server, account based wagering service) may query a database todetermine if a gaming session identifier is valid (e.g., correct, notexpired). A timestamp of a last check may be updated, and a gatewayand/or other component may be notified of a success or failure tovalidate the information.

In some embodiments, in response to a validation action taken inresponse to a received request, a request may be processed and/orinformation may be updated. For example, one or more timestamps of lastactions may be updated, one or more wagers may be placed, one or moreaccount transactions may be performed, requested information may beobtained, actions in a game may be taken (e.g., a hit in a blackjackgame), and so on. Some embodiments may include returning a result to amobile device (e.g., transmitting). Some embodiments may includepresenting such a result to a user.

Various examples of characteristics and methods validation should berecognized as non-limiting. Other embodiments may include no, similar,different, same, alternative, and so on methods and/or characteristics.

In some embodiments, if one or more validation actions of any describedmethod or other methods fails (e.g., if a variable is determined to beincorrect or expired, if a device is determined to be allowing externalcontrol, if a password is incorrect, if a location is not proper, etc.),one or more actions may be prevented and/or taken. For example, in someembodiments, a communication with a device may be prevented, wageringactions may be prevented, access to a gaming service may be halted, auser may be notified of an error, and so on.

FIG. 3 illustrates an example process that may be used in someembodiments for validation and/or use of a mobile device. Such a processmay include actions performed by a mobile device, actions performed by agaming application (e.g., a main application, a wrapper application, andso on), actions performed by a component of a gaming service and/oragent of a gaming service (e.g., a device authenticator service, acommunication provider, a location service, and so on) and/or actionsperformed as desired by any entity. For example, some embodiments mayinclude requesting an initiation of a location tracking of a mobiledevice, tracking a mobile device, providing location information about amobile device, determining if a customer has tampered with a clientand/or operating system, determining whether one or more communicationinterfaces are enabled and/or active, and so on. It should be recognizedthat such actions are given as non-limiting examples and that otherembodiments may include performing any actions in any order as desired.

FIG. 4 illustrates an example set of application that may be executed bya mobile device to facilitate access to a mobile gaming service. Suchapplications may include a wrapper application and a main application. Awrapper application may initiate execution of a main application andperform one or more security checks. A main application may performwagering actions in connection with a gaming service. It should berecognized that this example process and applications are given asnon-limiting examples only. Other embodiments may include different,same, additional, alternative, differently orders, and so on actsperformed by same and/or different entities and/or devices as desired.

Location Examples

Some embodiments may include one or more location determination featuresand/or features that may be affected by a location of a mobile device.Such features may include determining an actual location, determining arelative location, determining whether a location is a valid location,disabling a feature based on a location, enabling a feature based on alocation, adjusting a feature based on a location, and so on.

Geofencing Examples

One example location feature may include a geofencing service.Geofencing capability may be used to help ensure that a customer is/wasat an approved area (e.g., when a location check is performed, when awager request is received by a gateway, etc.). One example of ageofencing technology provider includes Sprint. In some embodiments,such geofencing technology may be used to determine whether a customeris/was at the city of Las Vegas, Reno, Tahoe and/or other gaminglocations in the state of Nevada that are geofenced. In someembodiments, customers may place sports and/or casino wagers if they(e.g., the device they are using) are/were physically in the boundariesof an approved geofence. In some embodiments customers may not placesports wagers if they are/were not in the boundaries.

A geofence may include a virtual perimeter of a real-world geographicarea. Some examples of parameters that may define a geofence around amajor city like Las Vegas, Reno, etc. may include: latitude 89.2 deg.,longitude 33.4 deg., radius 20 miles; and latitude 50.5 deg., longitude76.9 deg., radius 22 miles.

It should be recognized that any number of geofences in any locationwith any parameters may be used as desired. Geofences may be addedand/or removed at any time desired to increase, decrease, and/or changean area in which wagering is allow and/or not allow. For example,another set of example geofences may include: longitude 36° 05′ 58.37″N,latitude 115° 12′ 04.90″W, radius 20 miles; longitude 39° 38′ 58.68″N,latitude 119° 34′ 40.66″W, radius 20 miles; and longitude 39° 05′08.69″N, latitude 119° 34′ 10.61″W, radius 20 miles.

FIG. 5 illustrates an example of a series of geofences shown on a map ofNevada. The circles/discs in the map represent sample geofences. Agaming service may provide reasonable assurances that the customer iswagering in an approved area by using the capabilities that thesegeofences provide. In some embodiments, customers may be able to placesports wagers if and only if they are physically inside a geofence, ifan only if a last updated location (e.g., by a device authenticatorservice) shows that the device was last at an approved location, and soon. In some embodiments, customers cannot place sports wagers if theyare physically outside a geofence and/or were last determined tophysically be outside of a geofence. It should be recognized that whileexamples are given in terms of circles that any desired geofence shapemay be used (e.g., a geofence around a casino).

Some embodiments may include determining whether a device is in or outof one or more geofences. Such determination may include, for example, adetermination by a geofencing provider (e.g., based on gps coordinatesof the device and the geofence(s), based on triangulation throughcommunication devices (e.g., cell towers), and so on). In someembodiments, such a determination may include a determination by acomponent of a gaming service (e.g., by querying a location serviceprovider, by calculating a location, by receiving an indication, and soon). Geofencing may include Telematics hardware and/or software.

In some embodiments, when a device (e.g., a mobile device using a gamingservice, a location aware device, a device of a location-based service,etc.) enters or exits a geofence, the device and/or a component of agaming service (e.g., a device authenticator service) may receive agenerated notification (e.g., a provider of location services maytransmit a notice to a device indicating such a change in location).This notification might contain information about the location of thedevice (e.g., a current gps coordinates, a name of a geofence, a city,an indication that the device is in or out of a geofence, etc.). Such anotification may be transmitted to a mobile device over a communicationnetwork, to a component of a gaming service over a communicationnetwork, to an email account, as a text message (e.g., SMS), and so on.

Some embodiments may include taking any desired action in response to acrossing and/or near crossing of a geofence border. For example, inresponse to a leaving and/or near leaving of a geofenced area, a vehiclemay be stopped, a third party may be notified, a gaming service may benotified, a game may be stopped, a mobile device may be affected (e.g.,shut down, an application may be halted, and so on), and so on. Suchactions may be facilitated by a gaming service provider in response todetermining such a change to a location and/or a location serviceprovider.

As yet another example of a working of a location service, someembodiments may include a location service that may be queried asdesired to determine a location. For example, a communication serviceprovider (e.g., Sprint) may track a current location of a mobile deviceusing a communication service (e.g., through gps coordinates, throughcell towers or other communication access points being accessed, etc.).Such tracking may be performed continually and/or in response to arequest.

In some embodiments, a gaming service may transmit a query to verify alocation as desired. For example, a gaming service may transmit a queryto a location service whenever a variable has expired, periodically, inresponse to a query, etc. In some embodiments, such a query may ask thelocation service if a mobile device is in a boundary of one or moregeofences. In some embodiments, such a query may ask the locationservice for allocation of a mobile device and a gaming service maydetermine if the mobile device is in the one or more geofences bycomparing the location to the geofences.

In some embodiments, a gaming service may desire to minimizedeterminations and/or queries regarding locations. For example, suchdeterminations may require processing time that is desired for otherprocesses, and/or a location service may charge a fee for responding tosuch queries. Some embodiments may include a variable frequency and/orneed for such queries and/or determinations. Some embodiments mayinclude determining when to make a determination of a location based ona distance from boundary (e.g., a boundary of a geofence, a boundary ofan allowed gaming area) of a prior location determination.

For example, in some embodiments, a time between determinations (e.g.,periodic determinations, random determinations, occasionaldeterminations, and so on) of a location (e.g., a frequency of a query)may be greater if a device is farther from a boundary of a geofence thanif the device is closer to a boundary of the geofence. For example, alocation variable may remain valid for longer if it is based on thelocation that is farther from the boundary. In some embodiments, aresponse to a query may indicate when a next query should be made basedon such a distance. In some embodiments, a response to a query mayindicate a distance from a boundary (e.g., an actual distance, acategory of distance, and so on). A gaming service may determine when tomake a next query based on such received information. Such querying mayinclude for example, querying every 5 seconds for close to a boundary,every 15 second for far from a boundary, a sliding scale, and so on. Insome embodiments, a query may be made for every transaction when closeto a boundary, every other transaction when far from the boundary, andso on. A determination may be made that a request from a mobile devicedoes not require a location determination based on a distance from aboundary.

Some embodiments may include concentric geofences that may be used todetermine when a query of a location is to be made. For example, aninner geofence may correspond to a location far from an allowed boundaryand may correspond to a longer time frame. An outer geofence maycorrespond to an actual and/or closer boundary of an approved area andmay include a more frequent determination. Some embodiments may includedetermining whether a determination of a location of a mobile deviceshould be made based on the mobile device being outside of at least onegeofence and inside of at least one other geofence.

It should be recognized that such examples of a determination rate beingrelated to a distance form an edge of an approved area are given asnon-limiting and that other embodiments may include any methods and/orapparatus that may in any way relate determinations to distance may beused as desired.

Some embodiments may include determining such a determination rate basedon a speed of a mobile device. For example, in some embodiments, a speedof a mobile device may be determined based on a current and priorlocation (e.g., the distance traveled between determinations divided bythe time between determinations). In some embodiments, a fastertraveling device may be associated with a faster rate and a slower speedmay be associated with a slower rate.

In some embodiments, a speed and distance may be used to determine sucha determination rate. For example, determination rate may be determinedsuch that at a determined speed, a device is unable to travel a distanceto a boundary in a determined time, is unable to travel half a distanceto the boundary, is unable to travel any threshold percentage of adistance to a boundary, and so on.

In some embodiments, a direction may be used to determine such adetermination rate. For example, a direction may be determined based onprior two locations (e.g., traveling in the direction of the secondlocation from the first location). In some embodiments, a distance tothe boundary that may be used in determining a time period may be basedon a distance to the boundary in the direction of travel, a shortestdistance to the boundary in a range around the direction of travel(e.g., 20 degrees in either direction from the direction of travel, 90degrees in either direction form the direction of travel, and so on).

In some embodiments, a maximum time period may not be exceeded (e.g., 1minute, 5 seconds, 1 hour, 10 minutes, etc.).

It should be recognized that any actions, processes, information, and soon may be used to determine a determination period as desired in anycombination with any desired restrains.

Various other service may be offered by a location providing service.For example, Geofencing may be used with child location services tonotify parents when a child leaves a designated area. A location-basedservice may include an information and/or entertainment service, such asa mobile gaming service that may be accessible with mobile devicesthrough a mobile network. Such a service may make use of thegeographical position of a mobile device. LBS services can be used in avariety of contexts, such as health, work, personal life, etc. LBSservices may include services to identify a location of a person orobject, such as discovering the nearest banking cash machine or thewhereabouts of a friend or employee. LBS services may include parceltracking and vehicle tracking services. LBS can include mobile commercewhen taking the form of coupons or advertising directed at customersbased on their current location. They may include personalized weatherservices and even location-based games.

In some embodiments, technology may allow the creation of standaloneand/or overlapping geofences. Technology may allow creation of ageofence/circle of any given radius and/or shape. In some embodiments,this technology may prevent anyone outside of a fence from placingwagers. Geofencing may allow users of a system to draw zones aroundplaces of work, customer's sites and/or secure areas.

As an example, some embodiments may use a sandbox service for geofencingprovided by Sprint. Such a service is given as a non-limiting exampleonly. This service may include one or more geographical locations whereeach single position can be plotted with a geographic coordinate. A usermay be able to build a perimeter around this location—a fence, based onthose coordinates. Users of such a system may have the ability to buildfences, add devices related to those fences and be notified when adevice is entering or leaving (or both). In some embodiments, toalleviate privacy concerns, only devices having explicitly grantedaccess to an application may be able to interact with a geofence.

In some embodiments, one or more services may be available as part of ageofencing API to facilitate generating, eliminating, maintaining,querying, connecting, and so on regarding geofences. One or more of thefollowing examples of services may be available and/or used to providewagering services:

-   -   List—This service is used to return geofences associated with a        user.    -   list.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/list.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   key—Your API Key.        -   timestamp—The current time of the request:            [YYYY]-[MM]-[DD]T[HH]:[MM]:[SS][ZZZ]        -   [HH] refers to a zero-padded hour between 00 and 23 (where            00 is used to notate midnight at the start of a calendar            day).        -   sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   fenceId—ID of the fence associated with the user.        -   status—Whether or not the fence is currently active            (monitoring) or inactive (not monitoring).        -   startEndTime—The times between which the fence monitors (if            active), i.e. 915-1430, times are military.        -   days—Days the fence monitors (if active), note: H=Thurs,            A=Sat.        -   lastMonitor—Date\Time of the last check on this fence.        -   Latitude—Center latitude on which the fence is based.        -   longitude—Center longitude on which the fence is based.        -   dimensions—Dimensions of the fence (currently “radius” is v1            of geofence).    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/list?key=123abckey×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   110(Inactive, 900-1700, MTWHF, NEVER, 38.9178, −94.6598,            50),        -   427(Active, 930-1115, SA, NEVER, 38.9178, −94.6598, 500)    -   Add—This service is used to add a fence.    -   add.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/add.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   Name—The name of the fence.        -   strtTime—Earliest time to start monitoring the fence, format            [HH][MM] note: [HH] refers to a zero-padded hour between 00            and 23 (where 00 is used to notate midnight at the start of            a calendar day).        -   endTime—Latest time to monitor the fence, format [HH][MM]        -   note: [HH] refers to a zero-padded hour between 00 and 23            (where 00 is used to notate midnight at the start of a            calendar day).        -   Lat—Center latitude on which to base the fence.        -   Long—Center longitude on which to base the fence.        -   Dim—Dimensions of the fence (for v1 of geofence, this is the            radius).        -   Interval—The interval at which the fence should be checked;        -   note: only increments of 5 min may be allowed; i.e. 5, 15,            25, etc.        -   days—Days on which the fence should be monitored, as a            String with a single representing each day        -   note: H=Thurs, A=Sat; i.e. SMTWHFA.        -   notifyEvent—Whether the fence should notify on “in”, “out”            or “both” (excluding this param will default to “both”).        -   Timestamp—The current time of the request:            [YYYY]-[MM]-[DD]T[HH]:[MM]:[SS][ZZZ]        -   note: [HH] refers to a zero-padded hour between 00 and 23            (where 00 is used to notate midnight at the start of a            calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response:        -   message Success message if recipient was added or an error            message.    -   Example Request:        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/add?key=123abckey&name=My%20Fence&strtTime=900&endTime=1700&lat=38.917806&long=94.659787&dim=50&interval=15&days=MT                WHF×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   FENCE_ADDED    -   Activate—This service is used to activate an existing fence.    -   activate.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/activate.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   fenceId—The ID of the fence to activate.        -   Timestamp—The current time of the request:            [YYYY]-[HMM]-[DD]T[HH]:[MM]:[SS][ZZZ]        -   [HH] refers to a zero-padded hour between 00 and 23 (where            00 is used to notate midnight at the start of a calendar            day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   message: Success message if fence was activated or an error            message.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/activate?key=123abckey&fenceId=110×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   FENCE_ACTIVATED    -   Deactivate—This service is used to deactivate an existing fence.    -   deactivate.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/deactivate.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   fenceId—The ID of the fence to activate.        -   Timestamp—The current time of the request:            [YYYY]-[HMM]-[DD]T[HH]:[MM]:[SS][ZZZ]        -   [HH] refers to a zero-padded hour between 00 and 23 (where            00 is used to notate midnight at the start of a calendar            day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   message Success message if fence was deactivated or an error            message.    -   Example Request        -   Get:            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/deactivate?key=123abckey&fenceId=110×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   FENCE_DEACTIVATED            Some services may be used to maintain devices being tracked            in relation to a specific geofence. For example, the            following services may be used and/or offered for such            purposes in some embodiments:    -   List—This service is used to return all devices associated with        a geofence.    -   listDevices.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/listDevices.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   fenceId—The ID of the fence whose recipients you want            listed.        -   Timestamp—The current time of the request:            [YYYY]-[HMM]-[DD]T[HH]:[MM]:[SS][ZZZ]        -   [HH] refers to a zero-padded hour between 00 and 23 (where            00 is used to notate midnight at the start of a calendar            day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   deviceId ID of the device associated with the fence.        -   mdn MDN of the fence device.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/listDevices?key=123abckey&fenceId=110×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   1(8165551111), 14(9135552121)    -   Add—This service is used to add a device to a fence.    -   addDevice.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/addDevice.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   fenceId—The ID of the fence to add the device to.        -   Mdn—MDN of the device.        -   Timestamp—The current time of the request:            [YYYY]-[HMM]-[DD]T[HH]:[MM]:[SS][ZZZ]        -   [HH] refers to a zero-padded hour between 00 and 23 (where            00 is used to notate midnight at the start of a calendar            day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   message Success message if device was added or an error            message.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/addDevice?key=123abckey&fenceId=110&mdn=9135552121×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   DEVICE_ADDED    -   Delete—This service is used to delete an existing fence device.    -   deleteDevice.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/deleteDevice.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   deviceId—The ID of the device to delete.        -   Timestamp—The current time of the request:            [YYYY]-[MM]-[DD]T[HH]:[MM]:[SS][ZZZ] [HH] refers to a            zero-padded hour between 00 and 23 (where 00 is used to            notate midnight at the start of a calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   message Success message if device was deleted or an error            message.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/deleteDevice?key=123abckey&deviceId=217×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   DEVICE_DELETED            Some services may be used with respect to managing, and/or            receiving notifications for one or more geofences. For            example, the following services may be used and/or offered            for such purposes in some embodiments:    -   List—This service is used to return all recipients associated        with a geofence.    -   listRecipients.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/listRecipients.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   fenceId—The ID of the fence whose recipients you want            listed.        -   Timestamp—The current time of the request:            [YYYY]-[HMM]-[DD]T[HH]:[MM]:[SS][ZZZ] [HH] refers to a            zero-padded hour between 00 and 23 (where 00 is used to            notate midnight at the start of a calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   recipientId: ID of the recipient associated with the fence.        -   mdnURL: MDN or URL of the notification recipient.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/listRecipients?key=123abckey&fenceId=110×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   112(8165551111), 146(9135552121),            327(http://www.notifymyapp.com)    -   Add—This service is used to add a recipient (may be either an        MDN or URL) to a fence.    -   addRecipient.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/addRecipient.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   fenceId—The ID of the fence to add the recipient to.        -   mdnURL—MDN or URL for the notification recipient.        -   Timestamp—The current time of the request:            [YYYY]-[HMM]-[DD]T[HH]:[MM]:[SS][ZZZ] [HH] refers to a            zero-padded hour between 00 and 23 (where 00 is used to            notate midnight at the start of a calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   message Success message if recipient was added or an error            message.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/addRecipient?key=123abckey&fenceId=110&mdnURL=9135552121×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   RECIPIENT_ADDED    -   Delete—This service is used to delete an existing fence        notification recipient.    -   deleteRecipient.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/deleteRecipient.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Key—Your API Key, click here to view.        -   recipientId—The ID of the recipient to delete.        -   Timestamp—The current time of the request:            [YYYY]-[MM]-[DD]T[HH]:[MM]:[SS][ZZZ] note: [HH] refers to a            zero-padded hour between 00 and 23 (where 00 is used to            notate midnight at the start of a calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   message Success message if recipient was deleted or an error            message.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/deleteRecipient?key=123abckey&recipientId=217×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   RECIPIENT_DELETED    -   Perimeter Check—This service is used to determine if a device is        inside a defined area, or “fence.”    -   checkPerimeter.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/checkPerimeter.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Mdn—The MDN of the device to be located.        -   Key—Your API Key, click here to view.        -   Lat—The latitude of the center of the geofence.        -   Long—The longitude of the center of the geofence.        -   Rad—The size of the fence in meters.        -   Timestamp—The current time of the request:            [YYYY]-[MM]-[DD]T[HH]:[MM]:[SS][ZZZ] Note: [HH] refers to a            zero-padded hour between 00 and 23 (where 00 is used to            notate midnight at the start of a calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   Mdn—The mdn of the device that was located.        -   latReq—The requested latitude for the center of the fence.        -   lonReq—The requested longitude for the center of the fence.        -   radReq—The requested radius of the fence, in meters.        -   latRes—The actual latitude of the requested device.        -   lonRes—The actual longitude of the requested device.        -   Accuracy—The accuracy of the location fix for the device.        -   Status—The status of the request, meaning that if device is            inside or outside of the fence.        -   Comment—Additional information pertaining to the fence, this            is only displayed if there is an issue with one of your            parameters, e.g. your radius is smaller than your accuracy.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/checkPerimeter?key=123abckey&mdn=9135555151&lat=38.917806&long=−94.659787&rad=5×tamp=2010-0305T10:12:00CST&sig=123abcdef456    -   Example Response        -   9135555151,38.917806,−94.659787,5.0,38.914948,            −94.65723,0.0,OUTSIDE            Some embodiments may include one or more errors occurring            with respect to a geofence. Some example errors that may            occur include:    -   INVALID_LAT_LONG Latitude\Longitude is invalid.    -   INVALID COORDINATES Coordinates are invalid.    -   INVALID_ACTION Action (i.e. checkPerimeter, add, addRecipient,        etc) is    -   invalid.    -   INVALID_KEY Key is invalid.    -   INVALID_FENCE Fence referenced is invalid.    -   INVALID_FENCE_ID Fence ID is invalid.    -   INVALID_RECIPIENT Recipient referenced isn't valid.    -   INVALID_TIME Time entered for fence isn't valid.    -   INVALID_LATITUDE Latitude is not valid.    -   INVALID_LONGITUDE Longitude is not valid    -   INVALID_RADIUS Radius isn't valid.    -   EXPIRED_KEY The API key has expired.    -   INVALID_MDN Not a valid 10 digit number.    -   LOCATION_ERROR A service exception occurred on the server side.    -   EXHAUSTED_DIPS You have exceeded your transaction limit.    -   GENERAL_FAILURE An unidentified error may have occurred.        Some embodiments may include one or more services, functions,        processes, APIs and so on performed, used, and/or offered by a        device, and/or system that may interface and/or otherwise use a        geofencing technology. Some example functions may include:    -   Perimeter Check API—This service is used to determine if a        device is inside a defined area, or “fence.”    -   checkPerimeter.{format}        -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/checkPerimeter.            {format}?{params}    -   Authentication        -   This method requires a generated MD5 signature.    -   Arguments        -   Mdn—The MDN of the device to be located.        -   Key—Your API Key, click here to view.        -   Lat—The latitude of the center of the geofence.        -   Long—The longitude of the center of the geofence.        -   Rad—The size of the fence in meters.        -   Timestamp—The current time of the request:            [YYYY]-[MM]-[DD]T[HH]:[MM]:[SS][ZZZ] Note: [HH] refers to a            zero-padded hour between 00 and 23 (where 00 is used to            notate midnight at the start of a calendar day).        -   Sig—The MD5 Digest value of the parameters of the geofence            service and your secret.    -   Http Method        -   Get    -   Response        -   Mdn—The mdn of the device that was located.        -   latReq—The requested latitude for the center of the fence.        -   lonReq—The requested longitude for the center of the fence.        -   radReq—The requested radius of the fence, in meters.        -   latRes—The actual latitude of the requested device.        -   lonRes—The actual longitude of the requested device.        -   Accuracy—The accuracy of the location fix for the device.        -   Status—The status of the request, meaning that if device is            inside or outside of the fence.        -   Comment—Additional information pertaining to the fence, this            is only displayed if there is an issue with one of your            parameters, e.g. your radius is smaller than your accuracy.    -   Example Request        -   Get            -   http://sprintdevelopersandbox.com/developerSandbox/resources/v1/geofence/checkPerimeter?key=123abckey&mdn=9135555151&lat=38.917806&long=−94.659787&rad=5×tamp=2010-03-05T10:12:00CST&sig=123abcdef456    -   Example Response        -   9135555151,38.917806,−94.659787,5.0,38.914948,            −94.65723,0.0,OUTSIDE

FIG. 6 illustrates some example processes that may be performed in someembodiments with respect to a geofence. It should be recognized thatthis is given as an example only and that other embodiments may includeother processes, other actions in any order performed by any device asdesired. It should be recognized that various examples of servicesand/or functions are given as non-limiting examples only. Some suchexample processes may include creating a geofence, adding a device to betracked by the geofence, subtracting a device, eliminating a geofence,changing a geofence, querying regarding a device and/or geofence,listing active and/or inactive geofences, activating a geofence,deactivating a geofence, and so on. Other embodiments may include othersuch features with different parameters, authentication requirements,arguments, responses, names, and so on

FIG. 7 illustrates an example architecture that may be used in someembodiments for location determination. As illustrated, one or moremobile device may communicate with a gateway. Such a gateway maycommunicate with a location determination service. In some embodiments,the gateway may determine whether a location determination is desire d(e.g., in response to a wager, periodically, in response to a variablebecoming invalid, etc.). The gateway may query the location service inresponse to determining that the location determination should takeplace. The location service may determine a location (e.g., a gpscoordinate, a physical location, whether a device is in or out of ageofence, a distance to an edge of a boundary, etc.). The locationservice may transmit such location information to a gateway. The gatewaymay enable and/or disable a service as desired, store information aboutthe location, and/or perform any desired actions in response toreceiving the location information. It should be recognized that such anarchitecture and process are given as non-limiting examples only andthat other embodiments may include any desired components of a gamingservice, location service, communication service, and so on as desiredin any combination performing any functions.

It should be recognized that examples of determining whether a device isin or out of a geofence are given as non-limiting examples only. Someembodiments may include any number of services to provide such features.For example, a third party may provide location services, acommunication service provider may provide location services, a gamingservice may provide location services, any aspect of a locationdetermination may be performed in part or in whole by any entitydesired.

Soft Tag Examples

In some embodiments, in addition to and/or as an alternative togeofencing, a softtag system may be used. Such a system may be used todetermine whether a device is in an approved and/or an unapprovedlocation for gaming. In some embodiments, such a system may be providedby Ekahau to determine approved and/or unapproved (e.g., red/green)zones.

In some embodiments, such a softtag may include a gaming positioningclient software. Such software may be used, e.g., by a server,workstation, network, mobile device and/or processor, to facilitatedetermining information about a location or position of a mobile device.In some embodiments, such software may be used to identify a location ofa user of a mobile and/or handheld device (e.g., a moveable processor,such as a handheld computer, mobile phone or smartphone, laptop, otherportable electronic device, etc.). For example, software running on amobile device may cause the device to transmit or otherwise provideinformation (e.g., to a server or other processor, a unique identifier,a set of signal strengths, etc.) that can be used to determine theposition of the client mobile device.

In some embodiments, a gaming application (e.g., a main application, awrapper application, a softtag application, etc.) may perform one ormore actions to facilitate such features. For example, such anapplication may be assigned a unique identifier (e.g., as part of a signup process). As another example, such an application may be providedwith a list of allowed access points and/or a reference to where such alist may be obtained (e.g., from a gaming service). In some embodiments,such a gaming application may determine one or more signal strengthsform one or more wireless access points and/or one or more access pointidentifiers that may be accessed from a current location.). In someembodiments, an application may determine a network to which the mobiledevice is accessing a gaming service (e.g., a wifi network at a casino,a wifi network at a Starbucks in Las Vegas, and so on).

In some embodiments, one or more identifiers and/or signal strengths maybe transmitted to a gaming service and/or other location (e.g., with arequest to gamble). In some embodiments, an identifier of such a networkmay be used to determine that the network is approved. For example, thenetwork identifier may be compared with a listing of allowed networks(e.g., by a gaming service, by a mobile device, by the application). Ifthe network is in the list, then the network may be in an approvedlocation and gaming may be allowed. In some embodiments, a request to agaming service may include an identification of the network so that sucha determination may be made by the gaming service. In some embodiments,a set of signal strengths and/or access point identifiers may be used todetermine if a location is approved. For example, a set of signalstrengths and/or access points may be compared to a set of approvedsignal strengths and/or access points. Some example embodiments of suchcomparisons are described in U.S. patent application Ser. No.12/197,809, which is hereby incorporated herein by reference.

Some embodiments may include determining that a network is in an allowedlocation and/or identifying allowed signal strengths and/or accesspoints. For example, some embodiments may include an agent identifyingthat a network, access points, and/or signal strengths are in a allowedlocation to a gaming service (e.g., an agent may observe a boundary of anetwork and determine that the network is within a boundary of anallowed location, the agent may send a message to a gaming serviceidentifying that communication network and that it is in an allowedlocation, the agent may determine that signal strengths and/or accesspoints at various locations are valid and/or invalid based on thelocation compared to legal requirements). In response to receiving suchinformation, a gaming service may associate the communication network,signal strengths, and/or access points with being in an allowedlocation.

Such an application may run on any supported operating system orsystems. Such operating systems may include any operating systems forcomputers, servers, handheld devices, and/or other devices. Suchsupported operating systems may include Windows operating systems suchas Mobile 5 PocketPC, Windows Mobile 6 Classic, Windows Mobile 6Professional, and other operating systems, Mac operating systems, Linux,and other systems.

In some embodiments, the software may be capable of accomplishingvarious functions and have various features, including (but not limitedto) one or more (or all) of the following, e.g., in some embodiments:support client maintenance, e.g., from a Positioning Engine (e.g., aposition engine provided by the company Ekahau); adjust scan settings,e.g., for multiple devices, e.g., at the same time (or at multipledifferent times); display battery level status (e.g., from EkahauEngine); does not require Ekahau Client Connector; Supports Ekahau RTLS4.x Location and Maintenance Protocols (ELP, EMP); includes a new userinterface in the PPC Client: PPC Client settings are maintained usingEkahau Positioning Engine; Laptop Client may not have a UI: settings areset in the installer or settings are maintained using Ekahau PositioningEngine; and/or may or may not affect association/authentication.

Various examples of determining a time period for rechecking a locationare given elsewhere with respect to a geofencing embodiment. Suchfeature may apply to a softtagging or other embodiment. For example,particular networks, access point and/or signal strength sets may beassociated with different time periods between location checks based ona distance form an edge of a boundary of an approved area, a state, areliability, and so on. Similarly, speed of movement may be used todetermine such time periods in some embodiments.

It should be recognized that various examples of softtagging are givenas non-limiting examples only and that other methods and/or apparatusmay be used as desired. Any desire location services may be used incombination and/or exclusively. For examiner, some embodiments mayinclude determining that a device is both using an approved network andin a geofence.

Location Affinity Examples

Some embodiments may include associating a particular location with oneor more advertising elements, available games, user interfaces, skins,user accounts, and so on. For example, in some embodiments, a user thatis in the M Resort may be allowed to play games (e.g., sports wagers,and/or casino games) that may be allowed by the M Resort. For example,the user may be limited to only games that are offered by the M,approved by the M, have an M skin, and/or are otherwise limited and/orcustomized based on being located within the M Resort. In someembodiments, a user may be limited to using an account at the M Resortwhen located in the M Resort. In some embodiments, a user may be limitedto selecting an M Resort account from a list of accounts from which toplace wagers, an M Resort App, an M Resort menu item from a menu ofgaming items, and/or other elements related to the M Resort when in theM Resort. In some embodiments such restriction may apply to a particulartype of gaming such as casino gaming but may not to another type ofgaming, such as sports gaming.

For example, in some embodiments, if a user is in a geofence that isaround the M Resort, the user may be determined to be in the M Resort.For example, one of the geofences described above may be around the MResort and a query result from a location service may indicate whetherthe user is in or out of that particular geofence to be used by a gamingservice to determine whether the user is in or out of the M Resort. Insome embodiments, if a user is accessing a M Resort communicationnetwork for gaming (e.g., an M Resort wifi network), the user may bedetermined to be in the M Resort. In response to being determined to bein the M Resort, features may be enabled and/or disabled as desired(e.g., a user may be prevented from logging into a non-M Resort account.

In some embodiments, determining a location may be performed usinggeofencing such that a first geofence around a casino and a secondgeofence around a city may be used. For example, such a concentricgeofencing may allow for a user in a casino to be limited to thingsapproved by the casino, but a user outside of the casino to be allowedto use things approved outside the casino, which may include more,fewer, same, and/or different things than those approved in the casino.For example, more than one type of gaming may be allowed outside thecasino, such as sports wagers from multiple books not just the M Resortand/or casino games using money from accounts not located at the MResort.

In some embodiments, as an alternative and/or addition to determininglocation based on geofencing a determination of allocation may be basedon available communication networks. For example, one or moredeterminations may be made by a software application of a device as towhether one or more wireless networks or other communication networksfrom a set of pre-approved networks are available. Each such preapprovedcommunication may be associated with a particular location. If awireless network of the set of wireless networks is available, then thedevice may be required to establish a connection to that network inorder to play a game. Access to gaming through any other network such asa cellular network that may also be available may be prohibited when oneor more of the pre-approved networks are available. Accordingly, in someembodiments when inside of a casino such as the M Resort that may offera wireless connection to an M Resort network that is associated withbeing in the M Resort, a device may determine that the pre-approved MResort network is available. The device may stop access to a cellularnetwork for gaming purposes in response to determining that thepre-approved network is available. The device may connect to the MResort network in response to determining that the M Resort network isavailable. Limitations, abilities, restrictions and so on associatedwith being in the M Resort may be associated with gaming using the MResort network, and therefore, the device. Such limitations may beimposed upon the device by the device, by a server to which the deviceconnects, by a gateway through which the device connects, and/or in anyother way. For example, in some embodiments, based on an SSID on thenetwork, a gateway server may limit available accounts that may besigned into, based on the account signed into, a central server maylimit available gaming options, based on the SSID of the network, adevice may apply a skin and/or restrictions, based on an SSID a centralserver may apply limitations, and so on.

Such information about networks and/or locations may be used todistribute winnings, direct advertising, prevent users form becomingangry or feel cheated by a casino in which they are located even thoughthey are playing games that may be offered through another casino, andso on.

In some embodiments, to accomplish such network limited functionality, adevice may be configured to check for an availability of one or morepre-approved communication networks, such as a Wi-Fi connection (e.g.,by a gaming application, a wrapper application, etc.). Such checking maytake place periodically, continually, randomly, on demand, and so on.When any one of those pre-approved communication networks is available,the device may connect to that instead of any other network s. Ifmultiples are available, then a strongest signal or otherwise preferrednetwork may be used.

In some embodiments, to continue ensuring that no remote control is usedthrough a Wi-Fi_33 connection so that a player is physically present,when gaming through a cellular network, the Wi-Fi_33 may be disabled foractual data receipt and/or connection unless and/or until such apre-approved network is detect, a Wi-Fi_33 connection may be turned onfor mini boosts only to check if the network is available (in someembodiments, during which time the other gaming may be suspended), aWi-Fi_33 device may be on but unable to connect to any network acceptthe preapproved networks, a Wi-Fi_33 device may be controlled by aproprietary software that limits access to any networks other than thepreapproved networks, and so on.

When a pre-approved network is detected, a cellular network may be nolonger available for gambling through a gaming application (e.g., theapplication may be notified of the availability and disconnect from orotherwise limit access to a gaming server through the cellular network,a gaming server may be notified and limit access to games, and so on).The user may be prompted to login through the Wi-Fi_33 network and/ormay automatically be logged in through such a network instead. Similarlywhen the Wi-Fi_33 network is no longer available, if the cellularnetwork is available, the user may be prompted to login there and/or maybe automatically logged in there instead.

A start up process that may be performed before gaming is allowed on amobile device in such an embodiment may require that Wi-Fi_33 be enabledthroughout the use of the device, may require that a Wi-Fi_33 diagnosticbe passed, may require that an approved application has control over aWi-Fi_33 device, and so on. If no approved Wi-Fi_33 network isavailable, the cellular network may be used to gamble such as describedelsewhere herein, for example.

It should be recognized that various examples of location service and/orlocation affinity are given as non-limiting examples only.

Limiting Remote Control of Mobile Device Examples

In some embodiments, an ability to remotely access a cell phone may becontrolled. Such an ability may be restricted, prevented, and/or notavailable, for example. In some embodiments, one or more methods and/ordevices may be used to prevent remote connections to a mobile devicewhile a customer is performing wagering related activities using themobile device and/or if the mobile device is authorized to performwagering activities.

Some example mobile devices may include any number of communicationinterfaces (e.g., 4) that may be controlled to prevent remove access ofthe mobile device. It should be recognized that some embodiment mayinclude more, fewer, different such interfaces and that the exampleinterfaces are given as non-limiting examples only. Such exampleinterfaces may include 1. Wi-Fi, 2. Dock/USB, 3. Blue tooth, 4. CellularNetwork (may not support incoming connections).

In some embodiments, incoming remote connections to a mobile device maybe disabled, may not be possible and/or my otherwise may be preventedover a cellular network connection. In some embodiments, one or morecommunication interfaces may be disabled at a time relative to when aplayer performs wagering related activities (e.g. places a wager). Insome embodiments, such disabling may include preventing a customer fromremotely controlling a phone so that the customer may be at the locationof the phone when the wagering activity takes place. In someembodiments, if while in the sports betting application, the customerenables a disabled communication interface, and/or a remote connectionis made through such an interface, in response to determining that suchan enabling occurs and/or such a connection being made, a customer'ssports betting session may be terminated and/or disabled (e.g., with awarning message, without a warning message, a sports wageringapplication may be terminated, a communication session may beterminated, a gaming service may be notified, and so on).

In some embodiments, a mobile gaming application may make check todetermine whether a communication interface is enabled and/or whether acommunication session through such an interface is active. For example,an application may occasionally, in response to an action, periodically,and so on check if a communication interface is enabled and/or if acommunication session is active. Such a checking may be made by callingone or more APIs. For example, an Android OS API may be used. Someexamples of such APIS may include:

-   -   Class: UiModeManager    -   public int getCurrentModeType 0    -   Since: API Level 8    -   Return the current running mode type. May be    -   Configuration.UI_MODE_TYPE_NORMAL,        Configuration.UI_MODE_TYPE_DESK, and/or        Configuration.UI_MODE_TYPE_CAR    -   May check if device is docked or connected to USB    -   Class: WifiManager    -   public boolean isWifiEnabled 0    -   Since: API Level 1    -   Return whether Wi-Fi is enabled or disabled.    -   Returns true if Wi-Fi is enabled    -   See Also    -   getWifiState( )    -   May check if WIFI is enabled    -   Class: BlueToothAdapter    -   public boolean isEnabled 0    -   Since: API Level 5    -   Return true if Bluetooth is currently enabled and ready for use.    -   Equivalent to: getBluetoothState0==STATE_ON    -   Requires BLUETOOTH    -   Returns true if the local adapter is turned on

In some embodiments, a wagering application on a client device mayinclude one or more programs. A first application may include, forexample, an AIR 2.5 application built on Android 2.2 platform usingFlash AS3. A second application may include, for example an Androidwrapper application that launches and monitors the current devicestatus. In some embodiments, a customer facing application may include alauncher that may launch the AIR 2.5 application after checking thestatus of remote connection access points such as Wi-Fi, Bluetooth anddock. The application may be launched if all external connection methodsare disabled. Once successfully launched, if the customer enables one ormore of these access points, the application may terminate. If thecompliance validator service terminates and cannot provide status to theapplication, the application may terminate.

Some embodiments may prevent a user from making and/or accepting phonecalls. For example, an application may be closed if a phone call is madeand/or received during a gaming session and/or while a gamingapplication is being executed. In some embodiments, a user may beprevented from changing a focus, running multiple applications, runningother applications, and so on while a gaming application is executed. Itshould be recognized that any desired set of actions may be made toprevent remote access as desired.

It should be recognized that various examples of application arenon-limiting and that other embodiments may include a singleapplication, any number of applications, no applications, any language,any technology, any devices, any operating systems, and so on.

Example Components

Some embodiments may include one or more actors, programs, devices,servers, components, entities, architectures, and so on. Some examplesmay include:

A customer and/or mobile device user, a customer service agentassociated with a gaming operator that may be located at a gamingrelated property, a customer service help desk that may be accessiblevia a toll-free number for assistance to mobile customers (e.g., helpdesk information may be displayed to customer whenever any validationfails), an Android Wrapper Application (e.g., an application written inthe Android OS language and/or other language used to authenticatedevice and monitor phone status), an AIR Mobile gaming Client (e.g., aNGCB approved Adobe Flash application installed on the phone that may bethe current user interface to allow customers to sign-in, play mobilegaming, and view account history), a Device Authenticator Service (e.g.,an SSL secured service that provides the mechanism for the AndroidWrapper application to authorize the phone, a provider of an internal(i.e. only accessible inside the firewall) interface to validaterequests made to systems from approved devices), a gateway (e.g., an SSLsecured NGCB approved middleware communication service that proxiesrequests to DAS and the account based mobile gaming system), a Win32Wrapper Application (e.g., an Application written in the Win32 languageused to authenticate device and monitor PC status. It should berecognized that Win32 language and PCs are given as non-limitingexamples only and that that any technology may be used as desired. Insome embodiments, a mobile device may include a data adapter, a mobilephone, a smart phone, a laptop, a pda, and so on.

FIG. 8 illustrate example architectures that may be used in someembodiments. Some embodiments may include a mobile device as indicated.Such a device may communicate with a gaming service (e.g., a gateway).Such a device may be used by a customer to enter wagers, select games toplay, choose decisions in a game, log into an account, and so on. Someembodiments may include such a gateway and/or any desired components ofa gaming service and/or third party services that may be incommunication with a mobile device. Such a component may perform anydesired actions (e.g., authentication, location, and so on). Someembodiments may include a location service. Such a location service mayprovide any desired actions related to determining if a mobile device isin an approved location. Such a location service may communicate with amobile device and/or gaming service. Such a location service may includea communication provider for the mobile device, a gaming service itself,a third party, and so on. Some embodiments may include a gamingcomponent. Such a gaming component may be used to place bets, determinewager results, track accounts, and so on. Such a wager component may bepart of a gaming service provider. Such a gaming component may receivewagers, determine wager results, receive actions to take in a game,facilitate play of a game, transmit indications of a result of anaction, facilitate adjustments to an account in response to suchresults, and so on.

The figures illustrate that some actions may be performed by somedevices. It should be recognized that any desired actions may beperformed by any devices in other embodiments. It should be recognizedthat any desired computing devices in any combination may be used inother embodiments.

Some embodiments may use MD5 hashing and/or any desired encoding schemeto encode information, such as system parameters. Information about MD5hashing may be found at http://en.wikipedia.org/wiki/MD5. MD5 mayinclude a message digest algorithm for encoding data. MD5 may help toensure that 1) Once encoded, the data cannot be retrieved via forms ofdecoding (i.e. the original data is lost) 2) MD5 Hashing two differentpieces of data (even if they're quite similar) produces differentresults and/or 3) MD5 Hashing identical data will produce the sameresult.

Some embodiments may use an SSL HTTPS protocol to facilitate securecommunication between entities. In some embodiments, communicationbetween client devices and DAS, gateway, and/or a component of a gamingservice may be performed using via the SSL HTTPS protocol. This mayensure data integrity and/or security. Information about the HTTPSprotocol may be found at http://en.wikipedia.org/wiki/Https.

Some embodiments, such as those that may use an Android OS, may useprivate key signing to secure applications. For example, the OS mayensure: 1) two applications signed with different private keys cannotwrite to the data store of the other and/or 2) two applications signedwith the same private key can write to the data store of the other.Information about such security may be found athttp://developer.android.com/guide/topics/security/security.html.

Some embodiments, such as those that us Win32, may use process ids tosecure applications. For example, a Win32 wrapper application mayensure: 1) two applications are running under the same user id and/or 2)Two applications are the only two processes running under the same userid.

Such examples are given as non-limiting only. It should be recognizedthat various embodiments may include any desired actors, programs,devices, servers, components, entities, architectures, and so on in anydesired combination.

Examples of Gaming Rules

Some embodiments may operate in compliance with one or more rules. Itshould be recognized that any rules and/or no rules may be used asdesired. Any number of mechanisms, punishments, validations, and so onmay be used to ensure that any one or more of the rules are followed.Some examples rules may include:

1. Wagers are accepted within the approved geofences within the state ofNevada per Regulation 22.140 and Regulation 266.160. Nevada lawprohibits wagers originating from outside the State of Nevada so suchwagers may not be permitted. Accountholders may understand that it isillegal to place a wager originating outside the State of Nevada.

2. Applications for wagering may be made in person at a race and/orsports book. Applicants may complete the approved account based wageringapplication and provide acceptable valid proof of identification, and/orsocial security number, per Regulation 22 and 26c.

3. Account applicants may be twenty-one (21) years or older.

4. Account transactions may be made by the account holder. Accounts maybe limited to the use of the individual named on the application.Account deposits and withdrawals may be made in person. Agents or otherrepresentatives may not be permitted.

5. A minimum $100.00 deposit may be made to open an account. Deposits tothe accounts may be made in cash. Wire transfers may be made to apatron's account in accordance with Nevada Gaming regulations.

6. Account deposits and withdrawals may be signed and authorized by theguest at the race and sports book during normal business hours. Noagents or representatives may be allowed.

7. Account withdrawals and subsequent deposits may be made at thelocation where the funds were initially placed on deposit.

8. Account patrons may be required to provide their account number andacceptable valid identification when conducting account transactions inperson.

9. Wagers may not be accepted if they exceed the account balance.

10. Wagers may be subject to established wagering limits.

11. Rules, upon regulatory review, may be subject to change at any time.

12. Minimum deposit may include $100, and minimum wager may include $5.

13. Any desired house rules and/or regulations may apply to wageringaccounts.

14. Patrons may be provided, within a reasonable amount of time, astatement of their account showing wagering account deposits, wageringaccount withdrawals, credits to a wagering account, and/or debits to thewagering account made during the time period reported by the accountstatement. The request for such information may be done in writing andbe signed by the patron whose signature on the request will be verified.Within the request, the patron may furnish details on the dispensing ofthe requested information. All postal mailing may be done via regularmail to the address requested by the patron. If the request by thepatron is to personally receive the information, the information may begiven to the patron, who may provide valid identification when receivingthe information. The information may not be personally released toanyone but the patron who holds the account unless required by law orcourt order.

15. Patrons may dispute any transaction according to Nevada GamingCommission Regulation 7A.

16. Casinos may make a print, electronic or other approved record ofeach sports transaction and may not accept any such wager or transactionif the recording system is inoperable. Recorded wagering transactionsmay be maintained for 60 days, per Regulation 22 and 26c. The record ofthe patron's confirmation of all wagering information may be deemed tobe the transaction of record, regardless of what was recorded by thecomputerized bookmaking or pari-mutuel system. The records may be madeavailable to the Nevada Gaming Control Board upon request.

17. Guests may acknowledge that a wager placed using the system isbinding on both parties only when the BET IS APPROVED on the system orthe message “BET HAS BEEN ACCEPTED” is displayed.

Other Embodiments

It will be understood that the technologies described herein for making,using, or practicing various embodiments are but a subset of thepossible technologies that may be used for the same or similar purposes.The particular technologies described herein are not to be construed aslimiting. Rather, various embodiments contemplate alternate technologiesfor making, using, or practicing various embodiments.

Modifications, additions, or omissions may be made to the method withoutdeparting from the scope of the invention. The method may include more,fewer, or other steps. Additionally, steps may be performed in anysuitable order without departing from the scope of the invention.

While this disclosure has been described in terms of certain embodimentsand generally associated methods, alterations and permutations of theembodiments and methods will be apparent to those skilled in the art.Accordingly, the above description of example embodiments does notconstrain this disclosure. Other changes, substitutions, and alterationsare also possible without departing from the spirit and scope of thisdisclosure, as defined by the claims herein.

What is claimed is:
 1. An apparatus comprising: a machine readablemedium having stored thereon a set of instructions that are configuredto cause a processor to: determine that a device is authorized to use agaming service; determine that an operating system of the device isauthorized to use the gaming service; determine that a user of thedevice is authorized to use the gaming service; determine that thedevice is associated with a first location in which gaming activity isallowed; allow gaming activity based on the determination that thedevice is authorized, the determination that the operating system isauthorized, the determination that the user is authorized, and thedetermination that the device is associated with the first location;determine a period of time at which a determination that the device isassociated with a second location should be made based on a distance ofthe first location from a boundary of an area; determine that the periodof time has passed; and in response to determining that the period oftime has passed, determine whether the device is associated with asecond location in which gaming activity is allowed.